We illustrate how tests can be done in various ways. Tests can be part of code. It can be used as a check during a git commit. It can be set up automatically such that Pull Requests get verified by a Continuous Integration service like Travis.
The lesson covers a lot of aspects related to testing. It tilt some what towards testing with the purpose of software shipping. When testing with the purpose of verification and behavior specification is emphasized it becomes better and more well received.
Currently the lesson is in the “discipline” domain. Testing is something you do to control behavior (your own as well as the code). Testing is also something you can do to improve productivity, but this is less visible/detectable.
Every one know tests and do testing is a good thing. But do we stick to this? The motivation part start with a very strong claim, which put our non-tested code in the domain of “not science”. It is interesting to get views from the participants on the citation of Anthony Scopatz and Kathryn Huff.
The lesson then continues with:
These are valid points, but does not move “Testing” from the domain of something “we should do”, to the domain of “what we always do”. This is currently a weakness of the lesson (a point for discussion).
The examples work quite well. The pytest example can be done as type along. During the wrap up of the example with Travis, it is useful to have co-instructor doing the exercise in parallel with you. As your partner write Pull Requests with “fixes #1” (or whatever PR number) you can show that the PR links to a issue, and the issue pointing to a commit.
The lesson is stipulated to take 2 hours and 10 minutes. If the “Tools” and “Test Design” is skipped the lesson can shrink to a length of 90 minutes.
Splitting the lesson in two halves with a lunch break in the middle works very well. Before lunch you have on hour introduction and the two first exercises. After lunch you continue with “Automatic testing with Travis” and “Test Design”.