TDD is Like Riding a Bicycle
TDD is Like Riding a Bicycle
Learn about details about test-driven development and how to adopt it into your team with DevOps methodologies.
Join the DZone community and get the full member experience.Join For Free
Get the fastest log management and analysis with Graylog open source or enterprise edition free up to 5GB per day
From time to time I get to teach unit testing and TDD to developers. And every single time I get to learn something new.
During such class we got to the part where I talk about TDD. When I’ve explained about writing tests before code as a design activity - nobody objected. When we did step by step FizzBuzz kata together – everything was just rainbows and unicorns. Since the class seemed to grasp the concept of TDD I’ve decided to get their hands dirty with another TDD exercise – to do on their own (pair programming style) – and all hell broke loose… Actually it was fine, but obviously harder for the students. Some did better than others, keep in mind that it was the end of (a very long) day, it was the first time they ever attempted TDD and remember that these guys only found out about unit testing that same morning.
I did get very interesting results – as well as comments from the class.
After writing a few tests (doing TDD) one guy looked at me and said: “This is quite a lot of work, I think I can solve the problem faster without any unit tests...” I told him to try, but it made me think TDD and learning new skills. Any new skill requires practice in order to master it – think playing guitar, juggling or the ability to sleep late regardless of the amount of noise in your house (and an angry spouse trying to wake you up). In the beginning it’s hard and feels like a lot of effort for little gain and as time, as you improve it becomes easier and easier until one day you might become so good in what you do – it actually look easy to someone looking from the side.
It reminded me of learning to ride a bicycle – at first you might have trouble making the wheels turn, in this point you’ll probably move faster (and get where you want to go) without the bike (a.k.a walking) - just like the guy in my class – in this point he has better chance to solve his problem without TDD (with or without bugs). The next step is learning how to make semi-trusty vehicle stop, again doing what you did until now is the simplest possible solution – just put your legs down! But if you persist you learn that using brakes is better. After some time your brain translates “I need to stop” to whatever you need to do in order to make your bike stop.
As you get better in making your new mode of transportation go where you want to go it becomes easier and easier until one day you notice that you no longer think about the actual operation of riding the bicycles – you just do it. In that point it’s quicker to use your trusty (hello kitty pink?) bicycle to get wherever you need to be. At this stage you discover that you prefer riding your bike as oppose to the old way of “walking there”.
Same goes for TDD – in the beginning it might be hard and even seems like a waste of time – time you could have used to do something better (drink more coffee?) but as you progress you might find that it saves you time until one day you find out that it’s the way your brain solves design problems – automatically.
There is another aspect in which TDD is similar to riding bike:
Life is like riding a bicycle. To keep your balance, you must keep moving.
Al bert Einstein
Just like one of the smartest guys ever lived said – you need to keep moving if you want to avoid falling – which also reminded me of the Red-Green cycle – if you want it to succeed you have to keep short, quick iterations and try to avoid making too many stops along the way – but that’s a subject for another blog post.
Until then – Happy coding…
Published at DZone with permission of Dror Helper , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.