Managed developer testing

Monday 21 February 2005 — This is almost 20 years old. Be careful.

Kim writes about Managed Developer Testing, referring to an in-depth article by Alberto Savoia about “a set of management practices supported by automated tools which [he believes] are essential to make a developer testing effort successful“.

Kim says “our engineering team has nominally agreed that test-driven development is a good thing, but I’m having a lot of trouble keeping it going”. I know the problem. In my experience, there are a few factors that contribute to the impossibility of developer testing:

  • Developers aren’t used to writing tests, so we’re talking about a change of culture, which is hard.
  • Design for testability is rarely considered when architecting in the first place, so there are large chunks of code which are very difficult to test automatically. This contributes to developers’ sense that unit testing is a waste of time.
  • Developers have an in-born confidence in their code, so they view unit tests as a formality that won’t yield any benefit.

All of those are back-pressures on developer testing, but in my experience, the worst is this: The constant push to get the features “done” as quickly as possible. There’s little support in a traditionally-run engineering department to “hold up” the feature while the tests are written. Once it’s coded and seems to work, we say it’s done, then move on to the next feature. And of course if there isn’t a strong culture and infrastructure for automated developer testing already in place, any effort to start is going to bear the entire burden of creating the culture and infrastructure, so it’s a very high bar to get across.

As I’m learning with my personal projects, automated testing is a wonderful thing. I wish I knew how to get it in place on larger projects.

Comments

[gravatar]
Aggelos I. Orfanakos 11:55 PM on 21 Feb 2005
That's exactly my problem. Writing tests for small projects like a function that should return something is really easy and a wonderful thing. But things tend to change when you need to set up a bigger project and don't know what to start testing. I hope this is because I've almost never read anything on how it is done.
[gravatar]
Mark Eichin 1:33 AM on 23 Feb 2005
This is why some versions of TDD specifically talk about introducing it by writing the tests first and not writing *any* code that isn't "making a test pass" - because the traditional structures you describe *won't* support "test-later" in any useful way, you write the tests up front so that the effort "sticks" and there's no need to hold anything up later. Also, it helps with the feedback loop, because the test passing becomes *part* of the "yay it works" validation...
[gravatar]
David 8:01 PM on 2 Mar 2005
Michael Feathers' excellent book "Working Effectively with Legacy Code" is more or less entirely about the problem of bringing old hairy, nasty code under test. I recommend it highly!

Add a comment:

Ignore this:
Leave this empty:
Name is required. Either email or web are required. Email won't be displayed and I won't spam you. Your web site won't be indexed by search engines.
Don't put anything here:
Leave this empty:
Comment text is Markdown.