Planned changes to module 5.0

[andrewphilipsmith]

Some ideas (for future discussion with @edwardchalstrey1):

• Nowhere does it mention what we mean by a "test" in this context.
• Somewhere, it would be worth mentioning TTD. Not necessary in every project, but a useful discipline in learning to write testable production code. Also pushes toward a clear choice or functional or imperative coding.
• in 5.0 #Tests at different scales, include more detail eg
  • Importance of speed for unit tests
  • Component Testing can include using tests to tease out the expected/useful behaviour of 3rd party libraries where they are not adequately documented.
• 5.4 Mocking: mention it is (or can be hard). Also easy to fall into a trap of testing the implementation, not the result.
• include something about measuring test coverage
• Add cross-reference linting, pre-commit and CI in section 7
• Do we have an opinion on the use of assert statements in production code?
• Worth explaining numpy.testing.assert_allclose a bit more clearly? Or perhaps ignoring to focus on pytest

[jemrobinson]

• +1 for TTD
• I much prefer raising an explicit exception to using assert. I can't remember whether we've covered exceptions by this point though

[edwardchalstrey1]

@andrewphilipsmith I plan to take a look at the module today/ this week - one thing I would probably say is that for this round we can teach the course as is, and we may end up adding even more to your list at the end of it :)

[edwardchalstrey1]

Teaching notes:

• @andrewphilipsmith I'm pretty comfortable with most of the material, but not that familiar with mocking, have you done this much before?
• Similarly I'm a bit confused by the debugger notebook, what are we trying to show here?
• For the brief section on CI, we could show an example from a REG project that uses it (note this module is the day after Git, so they will have seen GitHub)
• The Monte Carlo example seems rather complicated for 30 mins, I feel like the students would take most of the time writing the algorithm rather than thinking about testing which is the objective. My suggestion would be for them in their groups to look at the solutions in the notebook and try to discuss amongst themselves the reasoning behind the way the tests are written and to play around with breaking them - what do you think?

Numpy pages

• https://numpy.org/doc/stable/reference/generated/numpy.testing.assert_allclose.html
• https://numpy.org/doc/stable/reference/generated/numpy.dtype.kind.html
• https://numpy.org/doc/stable/reference/generated/numpy.ndarray.ndim.html

[jack89roberts]

Also see #88 for suggestions from last time that we haven't got around to implementing yet