Sixth on our list is the tension between teaching the “what” and the “how” of programming. When we teach a scripting language like Python, we have to spend time up front on syntax, which leaves us only limited time for the development practices that we really want to focus on, but which are hard to grasp in the abstract. By comparison, version control and databases are straightforward: what you see is what you do is what you get.
We also don’t as good a job as we would like teaching testing. The mechanics of unit testing with an xUnit-style framework are straightforward, and it’s easy to come up with representative test cases for things like reformatting data files, but what should we tell scientists about testing the numerical parts of their applications? Once we’ve covered floating-point roundoff and the need to use “almost equal” instead of “exactly equal”, our learners quite reasonably ask, “What should I use as a tolerance for my computation?” for which nobody has a good answer.
How should testing be introduced?
I see that v4 of the lessons have an entire unit on testing, but it seems rather lengthy: http://software-carpentry.org/v4/test/index.html.
Reading through Software Carpentry: lessons learned, I see the following section (emphasis mine):