So, you want to learn TDD, huh? First off, let me ask a question 'why?'.
I'll tell you a story - few years ago, I had an apprentice, who wanted to learn TDD as well. We started working on a small project together for him to grasp the necessary skills through practice, with me sitting next to him, providing guidance. He showed up three, four times, then he resigned, having 'more urgent things' and 'no time'. Since then, he did not progress in TDD at all. Did he really want to learn?
See, sometimes people don't really want to learn something or don't want so much as to dedicate the necessary time and resources to this. Sometimes they just think they need to do it for whatever reasons - getting promotion at work, gaining a certificate, add something to CV or just 'stay up to date' with recent hypes, one of them being Test-Driven Development.
Others want to learn TDD for reasons they themselves made up. Knowing that TDD is valued and praised by others, they draw conclusions that it has to be good. Why is that so? Err... maybe... "the code will be more tested"? Or... ekhem... "the network of tests will be tighter"? And why do Test-First? Well... hmm... "to ensure tests are written for everything"? While these statements might be partially true, they don't even touch the essence of the "why" of TDD, and quickly turn into something like: "I don't really need TDD, because I need tests that give me confidence on broader scope"(*) or: "Why do I need unit tests when I already have integration tests, smoke tests, sanity tests, exploration tests...?". Then TDD gets abandoned, before actually ever being achieved in the first place.
You need to be highly motivated on this one. If you're not, hey, I heard the new series of Game Of Thrones is on the TV, why don't you check it out instead? Ok, I'm just teasing, however, as some say, TDD is "easy to learn, hard to master" (don't actually know who said it first, I searched the web and found it in few places where none of the writers gave credit to anyone else for it, so I decided just to mention that I'm not the one that coined this description) , so without some guts to move on, it will be hard.
How TDD feels like
Me and my brother liked to play video games in our childhood - one of the most memorable being Tekken 3 - a japanese tournament beat'em up for Sony Playstation. To finish the game with all warriors, unlock all hidden characters, mini-games etc. took about a day. Some could say the game had nothing to offer since then. Why then did we spend over a year on it?
It's because each fighter in the game had a lot of combos, kicks and punches that could be mixed in a variety of ways. Some were only usable in some situations, others were something you could throw at your opponent almost anytime without a big risk of being exposed to counterattacks. You could side-step to evade enemy's attacks and, most of all, you could kick another fighter up in the air where they could not block your attacks and you were able to land some nice attacks on them before they fell down. These in-the-air techniques were called "juggles". There were magazines that published a list of new possible juggles each month and the hype stayed in the gaming community for well over a year.
Yes, Tekken was easy to learn - you could put one hour into training the core moves of a character and then be able to "use them", but what made you a great fighter was the experience and knowledge on which techniques were risky or not, which ones could be used in which situations, which ones, if used one after another, gave the opponent little chance to counterattack etc. No wonder that soon, many tournaments sprang, where players could clash for glory, fame and rewards. Even today, you can watch some of the matches on youtube.
TDD is like Tekken. You've probably heard the mantra "red-green-refactor" or the general advice "write your test first, then the code", maybe you even did some experiments on your own where you were trying to implement a bubble-sort algorithm or other simple stuff by starting with a test. But that's all like practicing Tekken by trying out each move on its own on dummy opponent, without the context of real-world issues that make the fight really challenging. And while I think such exercises are (somewhat) useful, you need to understand the bigger picture.
Some people I talk with about TDD sum up what I say to them as: "That's really demotivating - there are so many things I have to watch out for that it makes me never want to start!". Easy, don't panic - remember the first time you tried to ride a bike - you must've been really far back then from knowing traffic regulations and following road signs, but that didn't really keep you away, did it? I myself found TDD very exciting. Some guys my age already think they know all about coding, are bored with it and can't wait until they move to management or requirements or business analysis, but hey! I have a new technique that makes my coding career challenging again! And it's not something I can use only when I pay to Microsoft or Oracle or anybody else - it's quite portable, making me a better developer overall!
(*)To be more precise, TDD is not only about unit tests, but is viewed as such by many.
No comments:
Post a Comment