Since the Given When Then section was added, I'd consider merging it with the Arrange-Act-Assert section (as it says, they are basically the same formula), perhaps a quick reference to one of them will be fine.
1.2 Types of Tests
Seems fine
2 Testing in JavaScript
Seems fine
2.1 Testing Examples
In the pure functions section, perhaps emphasize why pure functions are so popular -- they are easier to understand and grasp, and when it comes to coding, that allows us to write more bug-free code. Side-effects make it hard to keep track of things.
I'd delete the line "and maybe a few more test cases", and include any other test cases you would think of, for the purpose of educating the student
middlware -- typo
upto -- typo
2.2 Mocking
In the list of 'may be hard to test for because', I'd also include non-hermetic state, for example a GET request. In a test environment you wouldn't want to initiate an actual GET request. Perhaps this falls under "dependencies that are hard to provide", but this would be an extremely common example.
In the section for 'helps us write better tests', I feel like the bullet points are not really cohesive. I'd consider trying to put a summary at the beginning of every bullet point, like "Reduces setup:" and see if you can convey the main idea of each bullet point briefly (otherwise scrap it, or merge it with another one).
Monkey patching seems extremely dangerous and repetitive -- I don't think this is commonly used in production level code. I would suggest deleting this section, everything you want to do by manually monkey patching can be achieved using spies/mocks (as the next section mentions). Or at the very least, please include a warning not to do monkey patching at any real company (again, I'd prefer just to have students know that mocking/spying is the way to go about it).
2.3 Test Coverage
This section is fine
2.4 Static Analysis
It seems somewhat strange to me that this is under the testing section, but I suppose it doesn't fit anywhere else. I'd add a sentence somewhere about the limitations of static analysis -- code analysis can't understand everything about the code purely by analyzing it.
2.5 CI/CD
Specially -> Especially
devloper -- typo
I feel this section should at least mention Jenkins or TravisCI. There are some public servers where you can show examples of what these cycles look like (like open source projects' jenkin builds), I've found generally when teaching CI/CD for the first time that including concrete examples of setups is the most illuminating for students.
3 Testing pure functions
I think these two cases are actually the same in JS, as not passing a param causes undefined to be passed
Should return undefined when undefined value is passed as a parameter.
Should return undefined when parameter is not passed.
3.2 Testing Controllers
Weird formatting with the space before colons again, ctrl +f : (with a space before the colon)
The only thing I'd change is to emphasize that when testing API routes you should still be doing HTTP requests against a test server. For example, a test should never, ever ever be running HTTP requests against a production server.
1 Introduction to Testing
Seems fine
1.1 Testing Philosophy
Since the Given When Then section was added, I'd consider merging it with the Arrange-Act-Assert section (as it says, they are basically the same formula), perhaps a quick reference to one of them will be fine.
1.2 Types of Tests
Seems fine
2 Testing in JavaScript
Seems fine
2.1 Testing Examples
2.2 Mocking
2.3 Test Coverage
This section is fine
2.4 Static Analysis
It seems somewhat strange to me that this is under the testing section, but I suppose it doesn't fit anywhere else. I'd add a sentence somewhere about the limitations of static analysis -- code analysis can't understand everything about the code purely by analyzing it.
2.5 CI/CD
3 Testing pure functions
I think these two cases are actually the same in JS, as not passing a param causes undefined to be passed
3.2 Testing Controllers
Weird formatting with the space before colons again, ctrl +f
:(with a space before the colon)The only thing I'd change is to emphasize that when testing API routes you should still be doing HTTP requests against a test server. For example, a test should never, ever ever be running HTTP requests against a production server.
Other assignments look good.