Saturday, 19 July 2014

Developer testing ( continued)

Developer testing

In the last blog, I discussed about the four traps that discourages developers from testing. Let us consider some alternatives to these.

Test-early-and-often than test later
Explore than cover
Arsenal than one tool
Football (have fun!) than Foosball

As a developer, half of our time, we could spend in coding. The other half of the time, we should spend in testing. This is done best, when we test early and test often. Each of us could keep our styles, may be I would code for a day or two and then test for the next couple of days when you may be switching between the two every couple of hours. 

Developer testing is a deep reflection on what we have coded. Compiling the code is probably the first step in this. I suggest that the developer testing be an exploratory activity. Brave yourself to tread any path in your code fearlessly and be surprised at what you find there. Test the real code, use a stub when you are stuck.

The following excerpt from T S Eliot's "Little Gidding" is an apt metaphor about exploring.
We shall not cease from exploration
And the end of all our exploring 
Will be to arrive where we started 
And know the place for the first time


In my opinion, it may not be necessary to regress all your developer test cases each time. For ensuring the sanity of your design, you may consider a subset of test cases as a smoke suite. So this concern need not tie you up with a particular test tool. Build a rich arsenal; templates, data generators, test case generators, whatever. Code and test at will.

Developer testing is a reflective technique. For all you may, you could even stare at your code for half the time. There are no particular rules for developer testing other than those you follow for coding. Have fun at it as much as when you code.


No comments:

Post a Comment