There are a wide range of tools available to help manage the frantic rate of change often found in scientific domains. These tools and techniques hinge around the three pillars of modern development approaches: versioning, testing and automation.

With tight deadlines, developing software around scientific domains can mean that these tools are overlooked, with the developer's eyes focused on achieving a particular task. This post isn't about these tools per se, but how and when to employ them for maximum impact.

Correct

As an illustration, let's take a look at unit testing. Unit testing is an approach used to evaluate whether a software component behaves as intended. It requires a collection of assertions to be coded up independently of the central module, which exercises and tests the logic within. When reading up on unit testing, one quickly stumbles across a wealth of value added services to augment these tests:

• Test coverage: the proportion of exercised code is calculated
• Test driven design: tests are written before the modules they exercise
• Automated testing: automated build servers
• Functional and integration tests: controller, templates and integrated system tests
• User acceptance testing: working with users to evaluate usefulness
• Code randomization and limit tests: searching for uncaught edge cases

These tools represent a broader test framework, but the fear of not achieving a full, 'correct' implementation should not prevent a development team from getting started with their first unit tests. It is far more important to test the right things, than to be seen to be testing correctly.

Right
It is easy to put off testing on hearing tall tales of 100% test coverage (required in some companies, unbelievably) or dramatic, comprehensive test facilities, for fear that writing tests is an all or nothing venture, and opting for nothing. In practice, writing tests should focus on quality in the right place:

• The right scope
  Test only what needs testing: avoid testing methods already in place elsewhere.
  
  
• The right scale
  Building far reaching helpers or complex mocking is typically avoidable for most modules
  
  
• The right time
  The earlier the better!

By keeping these aims in mind, it is possible to implement both the required feature set whilst maintaining a solid test foundation beneath your application.

Review
Building a review period into a development timeline is a great way to evaluate current practices to highlight what's working, and what isn't. This is the place to think about ramping up a test framework to more advanced approaches as necessary, rather than never getting going because the scale of doing things 'correctly' is too vast.

"Agile" vs agile
A common misconception is that 'agile' development is a millstone: loaded down with jargon and heavyweight academic practices that fail to translate into the real world. However, by focussing less on doctrine and more on pragmatic use and review, modern tools and techniques can add tremendous value whist reducing risk and costs of scientific software projects.