Write some tests

[amcewen]

For the API server at least.

(Once we've got them we can hook up the Github CI to run them too)

[amcewen]

We discussed possibly using Cucumber (or a NodeJS equivalent).

When I've used it in the past I made these notes - copying them in here in case they're useful. This was on a Ruby on Rails, so it some of it might not apply to a NodeJS setup...

• The Testing Tuesday screencasts were a good primer, for example this intro to integration and unit testing.
• Here's a handy primer on writing good user stories
• The Cucumber wiki was a good starting point for getting to grips with Cucumber, particularly the Documentation section.

[JackiePease]

Looked at this tutorial: https://github.com/denford/tutecumber which introduces basic concepts

[amcewen]

Seems Simon Willison is also looking into testing and javascript, and writing up his exploration in simonw/datasette#1165 (he's also favouring Cypress, but then he's also been talking to Dracos, one of @zarino's colleagues :-)

[JackiePease]

"Quality Assurance and Testing with Chai" here: https://www.freecodecamp.org/learn
Lots of examples, but doesn't give much of an overview of the testing framework you'd run it in

[JackiePease]

I've installed Cypress (as an npm module) and ran a simple test to open the Booking System main page. This seems much easier than in Selenium, so I'll continue to explore Cypress.

[JakeWalker23]

Added some integration tests to branch feature/issue15-testframeworkexperiments which tests the /api/resources endpoint.

There is a small example of how to unit test a function that was in calendar.js.

Also looking at Github workflows that add CI into this project. It will be a good addition to the testing.

[JackiePease]

Hey - Are you around before Tuesday's meeting? I'll probably have a go at a test or so this afternoon/evening.

…

________________________________ From: Jake Walker <[email protected]> Sent: 24 January 2021 15:06 To: DoESLiverpool/optimism <[email protected]> Cc: Jackie Pease <[email protected]>; Assign <[email protected]> Subject: Re: [DoESLiverpool/optimism] Write some tests (#15) Added some integration tests to branch feature/issue15-testframeworkexperiments which tests the /api/resources endpoint. There is a small example of how to unit test a function that was in calendar.js. Also looking at Github workflows that add CI into this project. It will be a good addition to the testing. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub<#15 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ADBVRUG47HULYSL3YLZCDGTS3QZODANCNFSM4QSEBBRA>.

[JakeWalker23]

Hi Jackie,

Not tonight I have some other work to do. Give it a go, you might have to refactor the function so it does what you expect.

We can catch up tomorrow.

[JackiePease]

The meeting is tonight (just saw your email)

…

________________________________ From: Jake Walker <[email protected]> Sent: 01 February 2021 18:29 To: DoESLiverpool/optimism <[email protected]> Cc: Jackie Pease <[email protected]>; Assign <[email protected]> Subject: Re: [DoESLiverpool/optimism] Write some tests (#15) Hi Jackie, Not tonight I have some other work to do. Give it a go, you might have to refactor the function so it does what you expect. We can catch up tomorrow. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub<#15 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ADBVRUEC5DXQANR6MEZCNO3S43XHPANCNFSM4QSEBBRA>.

[amcewen]

@JakeWalker23 Good to see you've made some progress on it. Agreed that hooking in the CI would be good, feel free to spin that out as a separate issue (and start working on it too if you want), as I think it'd make more sense to run alongside the testing?

[JackiePease]

info from Jake:
Testing 'pyramid' gives context to what we are doing with our app, and as explained unit tests are what we want to implment because they are faster to run and cheaper to implement when it comes to debugging.

Integration:

An integration test is testing the integration of a request sent to our endpoint and the response it sends back. An example is sending a HTTP request to www.google.co.uk and Google then sending a response back with the content. A successful HTTP request returns a 200 HTTP response which is what we test for in our code attached.

In our code example we make a GET request to our endpoint (/api/resources/) which, after a slight refactor to the app.js file, sends back a 200 HTTP status for us to test for a successful request.

We can therefore test for the opposite with a bad endpoint (/api/resources/abcdefg) which returns a 404 HTTP status which equates to 'not found'.

Each endpoint created can be integration tested so there is potential for the other few endpoints to be implement this.

Unit:

A unit test is testing just one unit of code, most likely a function, to test that this piece of code returns what we want. For example if we had a function multiplyBy2() and passed in 2, we would assert/expect the output to be 4. This is an example of a unit testing a function.

code:

function multiplyBy2(number) {
return number * 2
}

We could then test this function similar to how we have done in the image attached with comments. It starts the same as our usual flow.

import our testing libraries (chai etc)

import our function to be tested (Lets use multiplyBy2() for now)

describe block {
it (tests that multiplyBy2 returns 2) {
// Given I have a value
let value = 2

// When I call multiplyBy2
 let result = multiplyBy2(value)


// Then I expect this value to be 4
expect(result).to.be.equal(4)

}
}

This is an example of a small unit test, but together these units add up to form a substantial testing suite. Each function ideally should have a test associated to it, so that is something to relay in the meetup!

To run the current tests associated on our branch, run npm t.

[JackiePease]

Initial tests written with Mocha and Chai have been merged with the Development branch