Automated testing fills entire books—I searched briefly and counted 20 devoted to the subject. Obviously I can’t cover it in a few short posts, and it’s not my purpose either. My purpose is to give you a few hints, and to explore how you, the non-computer scientist/engineer, can invest a reasonable amount of time and effort without needing to become an expert.
To round up this series, here are some things programmers (are supposed to) do differently. First of all, we distinguish between many different types of testing. The ones I’ve been talking about test your model as a whole, and they’re generally called “functional tests”. But a model typically has many functions, and we often test each one separately. These are called “unit tests” because they test units of functionality, such as functions. Unit tests are typically the majority. It’s easier to fix a bug if you know in which function it happened than if you simply know it’s somewhere in ten thousand lines of code.
We also sometimes use “test-driven development”, which is a whole different approach in coding. It means to first write the tests and then the code, but this is only part of the story; the rest is that we first write a test that fails, then just enough code, and no more, to make the test pass, then another test that fails, and so on. Test-driven development results in much more reliable and solid software.
Automated testing is an art and requires experience. However, if you just write a few functional tests for your model, and try to cover all edge cases, it’s OK. In fact, I’m sad to say that if you do this, you will be ahead of most professional programmers.