Testing should include more than just validating output - code reviews/concept reviews with others
When to test
While some strategies recommend writing automated test cases before any functionality (test driven development), a better approach that matches the flexible and changing nature of research software is to create tests after a requirement has been implemented. As developing comprehensive tests of software functionality can be a large burden to accrue at a single point in time, a recommended approach is to alternate between developing new functionality and designing tests to validate new functionality. Similar to the agile software development strategy, a build/test cycle can allow for quick cycles of validated functionality that help to provide input into additional phases of the software lifecycle.
What to test
In an ideal world, any software developed would be accompanied by 100% test coverage validating all aspects of functionality and interaction with other software. However, due to pressures of research, having enough time to build a perfect test suite isn't always realistic. A parsimonious application of the Pareto principle will go a long way towards improving overall software quality without adding too much testing burden. To apply this principle, spend some time in a thought experiment to determine answers to questions such as: "What is the most important aspect of this software," "If this software breaks
A combination of unit level and acceptance style testing - where tests are conducted to verify software meets requirements - is often best suited to the smaller scale and ad-hoc nature of research software. <reference dhh & is>.