When I use the phrase "Individual Developer Context", what does that mean?
My current defintion is "a set of tools and practices used by a developer to test the code that she writes."
DISCLAIMER: I have not worked as a developer. On a good day I can code my way out of a paper bag. My thoughts on the Individual Developer Context are based more on observation than personal experience.
The main traits of the Individual Developer Context as I have seen it practiced are that the tests are written by developers, the results are looked at by the developers, and the primary decision that is being influenced by the tests is code check-in. If the tests pass, the code can be checked into the main branch. If they don't pass, you have to fix them before checking them in.
Is there a difference between Individual Developer Context automation and automated unit testing? I'm not sure that there is. Wikipedia defines unit testing as "a method of testing that verifies the individual units of the source code are working properly. There may be tests written by an individual developer for his own code aren't unit tests. I can imagine a developer who works mostly by himself writing these kinds of tests. But I've never encountered them (if any of you have, I'd love to hear about them).
So what kind of tools are needed for effective Individual Developer Context automation? The critical piece is a tool for quickly creating and running low-level, granular tests. The xUnit framework has been widely proven as a solid tool for writing and running unit tests. For my own coding projects (some very crude stuff that I'm writing as a learning exercise) I use pyUnit. The other tool that I think is really useful for the Individual Developer Context is a code-coverage analyzer. Since these tests are written by the people writing the product code, they are best positioned to design new tests that will cover uncovered lines of code.
Monday, November 17, 2008
Wednesday, November 12, 2008
Saturday, November 1, 2008
Subscribe to:
Posts (Atom)
