Making Choices about What and How Much
How far do we break things up?
Do we test each individual thing exhaustively?
When to implement tests?
Exercise - Think about what to do with testing and the scenarios in the room
Get feedback from the room and come up with what people think is a reasonable and feasible approach to testing
Automated testing jobs
Automated tests can be run:
- Manually.
- At regular intervals.
- Every time code is commited to revision control.
A simple automatic triggering of automated tests is via a Unix cron
job.
A more advanced approach is via a continuous integration server. These trigger automated test runs and publish the results.
Show an example of a CI test server.
Tests are code
Review tests and avoid tests that:
- Pass when they should fail, false positives.
- Fail when they should pass, false negatives.
- Don't test anything.
def test_critical_correctness():
# TODO - will complete this tomorrow!
pass
Conclusion
Tests:
- Set-up expected outputs given known inputs.
- Run component on known inputs.
- Check if actual outputs match expected outputs - values if possible, form otherwise.
When to test:
- Always!
- Early. Don't wait till after the code's been used to generate data for an important paper, or been given to someone else.
- Often. So any bugs can be identified a.s.a.p. Bugs are easier to fix if they're identified at the time the relevant code is being actively developed.
- Turn bugs into assertions or tests. Check that bugs do not reappear.
When to finish:
- "It is nearly impossible to test software at the level of 100 percent of its logic paths", fact 32 in R. L. Glass (2002) Facts and Fallacies of Software Engineering (PDF).
- But, no excuse for not testing anything.
- When do you finish proof reading a paper? Learn from experience.
"If it's not tested, it's broken" - Bruce Eckel, in Thinking in Java, 3rd Edition.
"Testing is science" - Graham Jenson.