A little over a year ago I was fortunate enough to be able to take a 9 month break from work. I decided that in that time time I would hone my C# skills. I started working on a bunch of projects and forced myself to follow TDD.
It was a fairly enlightening process.
It was tough at first, but over time I learned how to write more testable code (which, as it turns out, tends to be more SOLID code) and in the process I also sharpened my OO design skill.
Now I'm back in the workforce and I'm noticing something odd.
I prefer not to follow TDD.
I find TDD slows me down and actually makes it harder to design a clean application.
Instead, I've adopted a slightly (massively) different approach:
- Pick a vertical slice of work
- Develop a functioning prototype
- Refactor until everything is nice and tidy
- Sit back an appreciate the beautifully SOLID and testable code I've written.
You may have noticed that step 1 wasn't "define the public surface of my test target" and step 2 wasn't "test the bejesus out of said public surface." You may have also noticed that none of the steps involve testing. I'm writing testable code, but I'm not testing it... just yet.
Now, I'd like to make it clear that I'm not actually foregoing any kind of testing. The code I'm writing works. It works because I'm testing it manually.
I'd also like to make it clear that I'm not foregoing all automated testing either. This is where my process is different. And this is why I'm asking this question.
TDD in theory. Not in practice.
My process has evolved a bit and I've struck a balance between TDD and no tests that I find very productive and also reasonably safe. It goes as follows:
- Implement a working vertical slice of work with testing in mind, but don't write any tests.
- If down the road (eg, a month later) that slice needs modification
- Write Unit Tests, Integration Tests, Behaviour Tests, etc that guarantee the slice of work is correct
- Modify the code
- If that slice doesn't need modification,
- Do nothing
By simply shifting the burden of writing tests from before writing the code to before modifying the code I've been able to produce much more working code. And, when I do get around to writing tests I write far fewer of them but cover nearly as much ground (higher ROI).
I like this process, but I'm concerned it might not scale well. Its success hinges on developers being diligent about writing tests before they change things. And that seems like a pretty big risk. But, TDD has the very same risk.
So, am I going to [BT]DD hell, or is this a common form of pragmatic coding and testing?
I'd like to keep working this way. What can I do to make this process work in the long term?Note:
I am the sole developer on my projects and I am responsible for everything: Requirements gathering, design, architecture, testing, deployment, etc. I suspect this is why my process is working.