Michael Bolton gave a list of things developers could do to make their code more testable recently on the Agile Testing list. I can usually remember 2 or 3 things like this when asked about this, so this is a much better list than I have come up with so far.

  • scriptable interfaces to the product, so that we can drive it more easily with automation
  • logging of activities within the program
  • monitoring of the internals of the application via another window or output over the network
  • simpler setup of the application
  • the ability to change settings or configuration of the application on the fly
  • clearer error/exception messages, including unique identifiers for specific points in the code, or WHICH damn file was not found
  • availability of modules separately for earlier integration-level testing
  • information about how the system is intended to work (ideally in the form of conversation or “live oracles” when that’s the most efficient mode of knowledge transfer)
  • information about what has already been tested (so we don’t repeat some else’s efforts)
  • access to source code for those of us who can read and interpret it
  • improved readability of the code (thanks to pairing and refactoring)
  • overall simplicity and modularity of the application
  • access to existing ad hoc (in the sense of “purpose-built”) test tools, and help in creating them where needed
  • proximity of testers to developers and other members of the project community

Off the top of my head, I would add

  • a ‘stub mode’ where you can test a module without needing another module reading / working
  • information about what has changed since the last code delivery in order to better target testing

I’m sure there is more.

Oh, and while we’re quoting Michael, in a post a couple weeks ago about The Dead Bee Heuristic.

I think what you’re trying to say is that if a bug is not repeatedly demonstrable, then it’s unclear as to whether an attempt at a fix will be successful. We call this the Dead Bee heuristic: when you’re inside a tent, and you think you’ve killed the bee, you want to see the body before you can sleep happily.

I’m starting to think that thinking in heuristics is easier with clear, non-techy examples like this.