30 Aug 2013
Test-Driven-Development. I understand the principles, I've read the books, I've gazed at source codes and other projects that successfully employ it, and yet I still don't use it in my work.
I've been developing NexGen since July 2011 and it's been operational and profitable since May 2012; I've released almost daily updates to the program and is now in a sort of plateaux where everything functions as expected and most of the remaining roadmap items are "nice to have".
The main problem I have is that my software is large, mature and mostly bug-free; retrofitting TDD could add bugs!
"If a company’s own research does not make a product obsolete, another’s will"Theodore Levitt
I'm not content with it's current incarnation, I want it simpler, faster and more useful. Further than that I want to be confident that if / when I leave the company and hand my work over to another developer that he has all the necessary tools to maintain and develop the product.
A big part of that is TDD; how could a stranger be confident that he hasn't b0rken everything? I think TDD would give that confidence.
I don't want to rewrite my code, but I do want to be able to test it. All of my important features are centred around database operations; as such my tests could be summed up as:
When I perform "X", the database MUST have valid structure.
Everything I've read about TDD has skirted around databases (mostly ignoring it altogether) and as such I have no inroad or lead to follow in order to design the tests that I deem most important.