Question

I find myself running my application quite often from the IDE, testing a lot of simpler changes and I find it bogs down my development time but if I don’t I’m afraid of bugs creeping up from previous dependent work. In larger product environment where it can take minutes to build – how often does everyone realistically test? How do you cope with potentially faulty code?

Answer 1

A few things that I do:

• Code defensively:
  • Use asserts liberally to test assumptions (can always turn asserts off for production code: although there are companies that ship code with assertions turn on to make diagnosing problem behaviour easier – even for up to ~30% overhead)
  • Mutual suspicion: always validate input to a unit before you use it
  • Whitelist instead of blacklist: it’s usually easier to specify what constitutes as “valid” behaviour than trying to enumerate all the ways something can fail.
• Code Review:
  • Use of code review process through open source software such as ReviewBoard has been shown to improve overall development speed / quality.
• Smoke testing: simple, inexpensive tests to check basic assumptions / behaviour before moving on to the longer tests – this can save you a lot of time.
• Unit testing:
  • Include self-contained tests for each unit of code that you write: a block of code, a function/method, a class, a package… and so on
  • As soon as the smallest block of code you write can be tested, test it – it will save you time down the line.
  • Utilize a a testing framework to run these together automatically
• Regression testing:
  • Test everything after changes go in to make sure nothing breaks. These typically take longer to run, so you may have to do these on nightly builds.
• Write tests before you write the code:
  • Writing tests first helps you understand exactly what the program is supposed to do / behave.
  • It helps you code exactly to specifications