Software Testing

Any time software is written as part of a research project, careful consideration should be employed on how to verify that the software performs the desired functionality and produces the desired output. As with bench science, software can often have un-expected and un-intended results due to minor or even major problems during the implementation process. In the software engineering field, software testing is a major component of any software development lifecycle and should also be a key component of research software.
Various methodologies exist for software testing and validation; furthermore, there are various strategies as to how software testing should be integrated into the software development lifecycle. Some common testing strategies are no strategy, manual testing, test driven development <reference>, large structured projects with testing phase, and mini iterations with testing along the way. While a full discussion of various methods and strategies is beyond the scope of this article, there are 3 key concepts that are common that should be addressed: when to start testing, what to test, and how to test?
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:
Once answers to these questions are known, spend time developing tests to validate key features, avoiding major negatives, and ensuring software performs adequately. 
How to test
Most programming languages have As mentioned previously, a pragmatic approach to testing 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.