50 years old test

Great blog post by Casey Charlton about TDD and unit tests - Testing Is Not Technically Hard, It Is Hard Because It Requires Clear Thought and Understanding which led to a long discussion on the TDD group about how to teach people to write a good test. Although the discussion was centred around TDD and unit tests it was a common testing discussion, very easy to write tests, not so easy to write good tests.

It is more and more common to read blogs from developers talking about testing and so I'll try and make it along to the next DeveloperDeveloperDeveloper! Day so I can listen to talks from people like Ben Hall talking about Microsoft Pex - The future of unit testing?

Sadly I was never exposed to any of this in my development days and took the classic code-release-fix approach and was always surprised when bugs were found in my code.
The situation outlined in this blog - Are your applications ‘legacy code’ before they even hit production? was all too familiar.

But if you don’t understand what was wrong with the last project you worked on, you’ll be doomed to repeat all of its mistakes. Even with the best of intentions, new legacy code is written, and without knowing it, you’ve created another maintenance nightmare just like the one before it.

Though after reading Jerry Weinbergs Perfect Software and other illusions about testing maybe I was in the era when devs didnt do testing. Jerry says

That's why I'm a strong advocate of the test-first philosophy, whereby developers write their tests to include expected results before they write a line of code. It's what we did fifty years ago, but the practice was gradually lost when industry trends separated testing from development.