The Individual Developer Context

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.

My GTAC Slides

Context Driven Automation Gtac 2008

View SlideShare presentation or Upload your own. (tags: automation testing)

My talk at GTAC 2008

What do I mean by Context Driven Automation?

I count myself a member of the Context-Driven school of testing. Context-Driven testers believe that the choice of testing practices should be driven by the context in which they are used. The practices that are appropriate for testing the control software for a CT scanner are not the same as the practices that are appropriate for testing a web-based email client.

I believe that the same is true for automation. The context in which the automation is being used should inform the design decisions about the tool.

In my experience, there are a few questions you should ask yourself to determine what your context is:

• Who is going to write and maintain the tests?
• Who is going to look at the test results and what information do they need to see?
• What decisions are going to be made based on the results from the automation?

In future posts, I'll address these questions, and other issues, in more detail.