Continuous Testing?


Continuous Testing?

I’m currently reading Bob Martin’s Clean Code. While I don’t agree with every word, I think it’s a very worthwhile book - even when I disagree, it makes me think. (And most of it’s spot-on.)

The chapter on unit tests talks about classic test-driven development (TDD), and describes a thirty second cycle of testing/coding. This got me thinking about the future of TDD.

One of the issues with testing is the separation of the tests from the code under test. I’m always switching back and forth between two units. Some languages (my boss mentioned Eiffel) already support the idea of “tests” (specifications, contracts, etc.) as integral parts of the code.

Not too many years ago, developers were used to writing code, then compiling it (wait, see if errors), then linking it (wait, see if errors), then (possibly) running a lint checker on it to detect more subtle issues. Modern IDEs show most syntax errors almost immediately. Plug-ins like ReSharper add more real-time diagnostics.

What if the IDE could run tests as we coded? I could start writing a test; as soon as it was complete, a red mark could appear in the margin (failed). I’d then start to write code to make it pass; as soon as that was done, the mark could turn green. Thirty seconds would seem positively glacial.

I can see it.

Your Host:
Copyright © 2000-2013 by William Sorensen. All rights reserved.