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.
No Comments/Pingbacks for this post yet...
Development Central is the blog of Bill Sorensen, a professional software developer. Much of this will relate to C#, .NET, and OOP in general.
Disclaimer
These postings are provided "AS IS" with no warranties and confer no rights.