This series of articles (The Truisms) is aimed at imparting some of the things we find to hold true no matter the project one undertakes in the space carved out by our interests in Open Source and Free Software engineering. The first article in the series was If you don't know why you're doing it, you shouldn't be doing it.

Many software developers, particularly those in open source projects, think that testing is somehow a dirty word. It's interesting that in commercial engagements it's often also not considered strongly worthwhile because there's a cost associated with it which is very visible, whereas the benefit of it is often much less obvious to the casual observer.

Testing, at whatever level you feel you can achieve, is always worthwhile. This is perhaps a controversial statement but I feel confident that I can support it. I have never been in a situation where I was unhappy that there were tests in a codebase. Sometimes they've been overly restrictive and made it hard to change how code behaves, but if the test author deliberately wanted that then they've served their purpose admirably.

There's plenty of different ways to test software. For some projects the easiest and most effective way to test is to have a human being use the software produced. For some it's possible to automatically test the outcomes of the project using tools such as yarn. Sometimes the best way to test code is at the unit-test level.

What's important is that no matter how you want to test your code (even if it's entirely by human), you need to have your tests written down in some manner which ensures consistency from test run to test run. For human-driven testing that involves ensuring that the test scripts are clear, not specific to particular computers and describe how to indicate where results deviate from expected ones. For automated tests that involves ensuring that the system under test is not affected by outside influences overly. Indeed ensuring that any external interfaces are mocked is a good way to ensure that a piece of software works in isolation from things which could affect the results adversely.

It's worth noting though that some things cannot be tested in isolation and need a wider set of systems available to test them effectively. So long as that wider set of systems is consistent and reproduceable, anyone can run your tests and satisfy themselves of the correctness of your project.

Anything you have not covered during testing is a potential thing which will cease to work and thus a candidate for removal from your project. Sometimes you cannot cover every line of code (particularly for covering defensive programming against unusual environmental errors) so exercise discretion here. But the big take-away from this is that if you are not systematically testing your software, bugs can and will creep in and bite you when you're not looking.

I could type in reams of examples of how testing has saved me, but I'm sure you don't want to read about those, so instead I shall set your homework for today. Find a project you have which is not properly tested and write some tests. Even if the tests all pass because you'd written perfect code before, you'll now be more confident that you can make changes to that codebase in the future and be able to know if you break something.