Before I start I’d like to point out that this is purely from my perspective and pretty much a subjective point of view. There are so many articles out there from an objective stand point, that I thought I do this from my own, seeing as personal accounts are pretty much one sided & usually only highlight the good points. Here, though I’m obviously a TDD advocate I will try to address the issues I have come across whilst working with the methodology.
I know I’m not the only one who hates spending hours trying to track a bug & have phrases like: “where did that bug come from?” and “i didn’t change that” swish around my brain.
Over the years I’ve learnt that there is no such thing as a perfect solution but have adopted TDD purely because I have always felt that software projects lacked the flexibility of car designers (who test our concepts before making a final decision). Being security conscious and taking pride in my work I thought it would be of benefit to explore the practice first hand.
I’ve always hated pros & cons, especially as some peoples pros are others cons, so I’ll just bullet each methodologies attributes that I am aware of, make of it what you will.
- Quick to initially code.
- No need for test suite.
- Cab be hard to trace errors & debug.
- Can leads to misconceptions in design.
- Changes could break existing code, without knowing and/or introducing new bugs.
- Developers feel uneasy making changes to the system.
- Debugging gets left to last or even out entirely due to time restraints.
- Functionality can get left out or reproduced.
- Need a test suite at hand.
- Able to test each module as its built.
- Easy to created dependencies within test cases.
- Ideas can be played with without actually implement production code.
- Need to adopt a different way of approaching problems.
- Easy to track when the application is deliverable.
- Errors/bugs can be picked up quicker.
- There is always something to test.
- Easy to recreate rare scenario’s/exception.
- Can take time to learn how to create useful tests.
With those points out of the way, I’ll explain my reasons for taking the testing route.
Though software development is maturing at a pace we still have an urgent need to track change & check our assumptions. The quicker we can check our assumptions are correct the quicker we’ll find bugs in our software, I’m the first to admit I get bored quick, when my attention wains so does the software I’m coding, whilst testing I find that I become more productive & my focus is more on problem at hand, rather than tracking errors or debugging as most of the errors are expected and handled quickly.
Below is a list of my loves & hates in regards to the testing process, like I mentioned earlier I don’t believe in perfect solutions so I think it prudent not to gloss over the fact that just because something is tested doesn’t mean it does what it is supposed to or that a project will end up better.
- Sped up my understanding of the problem at hand.
- Alerted me to error I’ve over seen.
- Easy to replicate hard to detect errors & exceptions.
- Allows me to test ideas before implementing them.
- Very handy when doing exploratory development (not sure how something works).
- Creating useful tests can take time to learn.
- Just because a test passes, doesn’t mean it is bug free.
- Is easy to create useless tests.
- If not careful planned, can find yourself testing more than creating production code.
From personal experience I found that once I grasped the concepts of testing (more so the TDD process, which I’ll go over in later blogs), the quicker I was able to implement functional code, whilst allowing me to test out assumptions I may have had. This along with a few other techniques (mainly design patterns & refactoring) has evolved my programming allowing me to create flexible, reusable code which I end up using in a range of projects.