Hey all,
Earlier this year I realised I had been struggling with a few development concepts that seem pretty mandatory to the market. I've since made it a point to look out for design patterns, think about writing 'testable code' and applying sensible refactoring.
One concept that I feel is surrounded by a lot of disagreement and confusion is TDD. There are developers who love it and can't agree on a TDD approach to follow and there are those who just out right hate it. The general development market seems to think of it as a god-send and that every developer needs to be an expert at it, but there are developers out there who follow a develop-then-test methodology and still end up with very robust, well tested code.
Naturally, I began to ask the "why does this matter, seriously?" questions and not long after decided that the best way of figuring it all out was to follow an uncompromising TDD approach for all of my development. The only sensible way of making my mind up was to throw myself to the TDD ocean and to see if I drowned. Barring some annoyances, I'm actually handling it quite well and I've come to see a few huge benefits from using Test Driven Development. Working directly from requirements, constructing testable interfaces and the huge step up in knowledge of testing libraries like Mockito and Hamcrest have been some of the advantages I've witnessed from using a TDD approach. However, these advantages haven't come without serious frustrations.
In a series of posts, I'll glace over some of the hurdles I've had to overcome in my TDD adventure, and the lessons I've learned as a result!
The first post, coming very soon, is about 'Developing the Bare Minimum to Pass a Test'.
Stay Tuned!
Shrek
No comments:
Post a Comment