TDD is dead?!? Let's do an autospy (ncrafts.io)
•
2 likes•1,985 views
Why we are still stuck with TDD nowadays? Through several facts & stories from the trenches, we will see why most of us still have not managed to grasp or to sustain the TDD experience. Wouldn't be a good opportunity to meditate about how we are thinking? And why not, thinking outside of the box to get a better feeling of the TDD soul.
Recommended
Recommended
More Related Content
Viewers also liked
Viewers also liked (17)
More from Thomas Pierrain
More from Thomas Pierrain (17)
Recently uploaded
Recently uploaded (20)
TDD is dead?!? Let's do an autospy (ncrafts.io)
Editor's Notes
- Thomas: Hi everyone! Welcome to our autopsy session of TDD Bruno: I'm Bruno. I'm an agile coach and also a software craftsman. Currently, I transform developers as software craftsmen for a major bank. I have cofounded Learn to Craft with Jean Laurent de Morlhon. This is a specific training about software craftsmanship. Thomas: I’m Thomas. I am technical architect for a large investment bank, but also developer – including the open source- with NFluent .NET library that makes it easier to write readable assertions and "helpers" in your tests. I practice TDD-almost exclusively since 2005, when I also discovered XP (thanks to this gentleman, there next;-)
- The idea of this talk came from an observation: all developers have probably heard -at least once- about the Red-Green-Refactor TDD mantra. (Question for the audience-QFTA) Can you please raise a hand if you already heard about it (I’m expecting to see everyone here ;-)
- Thomas: Ok. Let’s start with a short reminder to clarify our ubiquitous language for the session: RED It all starts with a test that is written when the code does not exist yet. In fact it brings out a skeleton for this implementation when writing our test GREEN We just wrote the code for the test to pass as quickly as possible. We can take many shortcuts here. The objective is to make it green ASAP. REFACTOR The part that is too often sacrificed: Once our has passed, we improve our code to replace all shortcuts we’ve taken, all the smells codes etc. Ok then. Everyone has heard at least once about that… but when you look around and see how many TDD practitioners you can find in the projects, when you talk with others in the various meetups, or on tweeter… Almost no one practices TDD today. (QFTA): Can you please raise your hand if you are practicing TDD on a daily basis at work? Bruno: With Thomas we think it is normal ... If you think about it, there are very few books or blogs that explain the whole TDD process. How we capture the business needs, how we feel the emergent design... TDD is a lot more than that, it is also hard at first. There are some pitfalls, false positives, and we can be very disappointed if we start in the wrong direction. Thomas: Thus, the objective of this session is to have an overview of TDD main difficulties; and for us to propose hints and tricks from the trenches to help you to retry the TDD experience … successfully this time.
- Why should you retry the TDD experience? Reassuring to manage complexity, to guard from regression also Efficient: because it’s a straight to the point approach, with YAGNI principle at the heart of it. We really limit ourselves to the essentials and avoid tunnel effect. It’s also really Encouraging: I don’t know for you guys, but since a developer’s day may be full of negative feedbacks (from the compiler, from the project manager, from the end users, etc), any kind of positive feedback is really welcomed to encourage me. Here, every Green light -when a test passed- is like a candy, a small victory. Very encouraging to move forward.
- To understand the soul of TDD, it should better to think out of the box before to go further. Don’t be afraid, we come back in few minutes. Imagine that you are at the end of the fifteen century …
- Imagine that you are at the end of the fifteen century … where the middle age isn’t completely terminated. At the same time, there is bunch of craftsmen, artists and intellectuals that wanted to get rid off the middle age and reinvent art and life. This new movement is … … the Renaissance. Several of these artists are still famous nowadays. But there is one, I’m really fan of. A sculptor. This guy has a amazing skill … … when he touch a block of marble, it is able to feel his nascent character through the stone. Click - Realize: the guy has just to touch A stone to feel and imagine the upcoming sculpture. Click -This guy was Michelangelo. But who was Michelangelo? Click - He was only six years old when he is loose his mother. Click - His father placed him with a family nourished stonemasons. Click - With the children of this family, he will cut the stones before he can read and write. He will confess, many years after that he had discovered a real a pleasure to break stone during his childhood with this family. After, for a while, he got a long experience through several studios where he has beaten each masters. Click -His talent allows him to join the art school of Lorenzo de Medici .He learns also poetry, literature and of course continues to improve in drawing, painting and sculpture. Click -Michelangelo spent many nights to cut human bodies to better transcend them. It was forbidden, it was hard and difficult, but it was tolerated if you were an artist and if you come only during the night.
- Click -Michelangelo finds its artistic peak through a giant David (4.34 m high) of white marble. He draws and sculpts it between 1501 and 1504. David, a character from the Old Testament, is featured naked young man, muscular gauging his enemy Goliath. But unlike traditional representation, where David was represented after the fight with a soldier posture. [PAUSE] . Click -Reveals the moment of inner reflection Click -It captures interiority. Click -David became the symbol of the invincibility of the Florentine Republic.
- That was very interesting Bruno, but what’s the link with our topic actually? I am a developer; not a brilliant artist ... Bruno: As you probably figured out, Michelangelo was a crazy workaholic ;-)
- Bruno: As you probably figured out, Michelangelo was a crazy workaholic ;-) Thomas: Yes, as you just explained, he started to cut stone when he was 6. That should have given him a kind of edge, comparing to the other sculptors It makes me think of the theory of 10,000 hours. (QFTA) Who already heard about this 10k hours theory? It’s a theory from a Swedish psychologist (named Ericsson) that is stating that to be an expert in any field, you have to spend at least 10 thousands hours of practice and workout. This applies to any kind of Craftsmanship, arts, sports, martial arts, or even poker. There is something funny with Poker actually. Rather than hours, the experience of Poker players is driven by the number of hands they have played. That explained why so many young poker players recently beat old and very experienced players during the World series in Las Vegas. With online poker, those 20 years old players had played more hands in their short lives, than old school poker players in their entire carrier. Indeed: online you can play whenever you want 24-7, and you can also play multiple tables simultaneously (this is called: multi-tabling) This rule also applies to DEV. Source: http://www.1000words-a-day.com/wp-content/uploads/2011/06/10khrs.jpg http://www.sculpteur-petrus.com/images/sculpture-21-2.jpg http://www.menshealth.fr/wp-content/uploads/2014/04/HITT.jpg http://www.afacsport.com/wp-content/uploads/2012/05/taichi.jpg http://www.peppermillreno.com/library/images/backgrounds/gaming_poker_cards.jpg
- Thomas: When we workout, when we code and do some code kata for instance, this has direct action on our brain. Repetition is changing our synapses connections & brain configuration (animation) It’s like in JAVA or .NET: the JIT compiler optimizes the execution of a method, or a piece of code based on its number of calls Our brain is somehow similar. If we master our tools and the way we code, we can then focus on what's important: the value for our domain, business and software. Bruno: The Neo character is based this idea. After a long training his brain is different. It enable to see inside the matrix and for him the bullets arrive slowly. Thomas: This Neo thing reminds me the first time I learned to drive a car with my GranPa; there have been so many things to keep in mind: the steering wheel, the right foot, the left foot, the gear lever, the reer-view miror, etc. It was on a parking lot and I couldn’t hurt my GranPa car in the tiny walls. I was overwhelmed by all those details. Now we I drive my car… Pfff ;-) Bruno A friend of mine told me that repetitions were not a good approach. If we analyze the Modern Time movie, we are not in the same posture. You decide yourself to repeat something because we are motivated by something, is different when someone force you to repeat something.
- As I said in introduction, I turn developers in software craftsmen. This coaching is mainly based on code kata: greenfield and brownfield. At the end, we practice some coding dojo to share their perceptions together.
- Pierre is friend of mine. He loves to software quality and he decide to start his new career plans in TDD. However. when he is faced with the code editor, it sometimes feels helpless and unable to produce code. He finally stopped and now says that TDD is very difficult. This is the first cause of TDD’s failure. public: Ask the public its opinion
- Bruno: Developers forget to be well informed on the subject before coding, forget to communicate. Reflection is undoubtedly a crucial part of TDD. Thomas: For the emerging design overwhelms us, you must prepare your brain.
- Thomas (the title "Why Should"?) About shoulds besides myself who practice TDD since 2005, it's true that I did not use this formulation. My name was on the test requirements, and when we discussed this both goshawks of the coffee machine there are more than a year, I thought I was going to try to follow this technique. Well I must say that the results thereof to structure very clearly what we will do / write to the next test is really super effective! Bruno (with animation "Should such a message to yourself - >>) Example of the use of the shoulds Fruitshop kata.
- Jean is a colleague who practices development with great professionalism, but with the TDD it did not go well. He wanted to start TDD gradually in their daily work. Very quickly, he soon realized that productivity had dropped significantly. Facing the end of his project, he preferred to stop TDD. public: Ask the public its opinion
- Thomas: Seriously guys? We –developers- are all LANNISTERS … There is always a time where we pay our Debts ;-) You can test-after to let your project manager think that you’ve finished your job earlier… but you know that you will test – or worst- troubleshoot your app under production- afterwards. Some recent studies made by various MS showed that TDD was adding 15% up to 35%. I would have said 10% for me, that is doing TDD almost exclusively since 2005 https://twitter.com/Cyrdup/status/589774288904912896 http://memegenerator.net/instance/60954764
- Thomas: But anyway. You know what? Typing is not the bottleneck… THINKING IS the bottleneck! http://start.sbastn.com/typing-is-not-the-bottleneck
- Thomas: of course, without thinking, you feel faster! But it’s a lie. Right Bruno? Bruno: Click -In Public: If I say “Winter is …” you tell me… (coming). Or in french: “Une hirondelle ne fait pas le ….” (printemps) Click -Now, if I ask you 17 x 24? You tell me…. ;-) 408 Which was easier for you? … That’s normal. Indeed, our way of thinking is divided into two systems that work together but are totally different. System 1 is fast and relies on automation and various types of bias that lead us astray often, but it is quick and no tiring System 2 is slow, as it requires us to mobilize ourselves intellectually to think, to reason. He demands of energy (sugar) and we tired quickly. However the system and logic is wrong unless the system 1. Our lives are largely based on the system 1, but if we want to do TDD, you must request your system 2, which by nature is slower. TDD produces a code test in terms of behavior, so it is normal that it costs more than a little or not tested program. Source: http://www.google.fr/url?source=imglanding&ct=img&q=http://i.dailymail.co.uk/i/pix/2013/10/20/article-2469485-1753A9F8000005DC-917_634x408.jpg&sa=X&ei=EXpTVZyVFOrfywOKnIDYBw&ved=0CAkQ8wc&usg=AFQjCNHjtSbsIGjlJw3u1SJgjPjNWJBMJQ
- It Bruno reminds me my case. There are a few years, I was technical lead on a pricer, it was between 4 and 8 in the team and we had set some standard on our app. TDD, par, at least 80% of test coverage, test acceptance of black box, unit testing, parallel run etc. We release every 15 days, and with this device: it even happened to me releaser and go find my darling to the movies or the theater just after. In short, it was super confident in our device. And then one day, after one year of developping our pricer and our code base, we realized that we faced serious difficulties every time we would like to change or to add a new feature. Indeed, almost 10 or 20% of our tests were breaking every time.... Not the blackbox-acceptance tests, but most of our unit tests… We needed to rewrite them. Our tests were brittle/fragile and made us suffer. In short they have started to slow us down and we started to wonder what we could do to get there ... I even began to make me challenged by management who asked us to stop TDD, saying we must remain productive again at the end of the day. What did we got wrong? Was it related to the important number of tests? Was it related to the way we were written those test? We collectively thought about it, and then figure it out that it was related to how we were written our tests ;-( Our unit tests were too much implementation-oriented.
- The secret to avoid that kind of situation? Do not test methods or implementation details Instead, test behaviours – even at the unit test level. This is crucial to practice TDD safely. Source : http://upload.wikimedia.org/wikipedia/commons/c/c0/Behaviour_Santiago_Logo.jpg
- Bruno: Poor test code because it does not bring value. Both tests are procedures and not on a script
- Bruno: In this version of the code is simple and clean. The test covers a scenario perfectly explained through his name.
- Thomas: Another feedback we often hear: « I have the feeling to dedicate too much time to the writting of tests, and not enough time to write code for our app. Is TDD really efficient? »
- EFFICIENCY VIA MINIMALISM & SHORT FEEDBACKS Source : https://c2.staticflickr.com/8/7135/7021453805_b2b981d7c0.jpg http://blog.leanmonitor.com/wp-content/uploads/2014/08/minimum-viable-product.png KISS http://www.google.fr/imgres?imgurl=http%3A%2F%2Fpg.nooidea.com%2Fupload%2F2011%2F02%2F21%2F20110221065459-272e0930.jpg&imgrefurl=http%3A%2F%2Fwww.nooidea.com%2F2011%2F02%2Fkeep-it-simple-stupid.html&h=500&w=486&tbnid=7IRRI2o8BoLQGM%3A&zoom=1&docid=iIioXZg6ISiYxM&ei=60UiVY7LAYLvUJWdgLgC&tbm=isch&iact=rc&uact=3&dur=2630&page=2&start=25&ndsp=30&ved=0CJABEK0DMCM
- Thomas: When I started to practice TDD in 2005, I was practicing the CLASSIC style of TDD. Red-Green-Refactor, you start from the inside, and you rely on triangulation to improve your implementation or to add more and more behaviours from the inside by increment. This is nice, but you can also be victim of tunnel effects ... And realize too late that you arrived in a situation far from what you really need.
- Thomas: This is why I now practice almost exclusively the Outside-in form of TDD (also called the London school). In that form, you consider your system as a black box. An empty one a the very beginning, and … <explications>. Bruno: As Michelangelo, we shape the code at the coarse grained level, but after we shape the fine grained level.
- (reminder: Kent Beck’s 4 rules of simple design: It passes all the tests It minimizes duplication in all its forms It expresses its intent clearly to the reader It removes unnecessary elements)
- TDD can truly change your life as a developer, to make it more comfortable, reassuring, efficient
- Thomas: Le cas du diamonds kata illustré par Seb ROSE et que j’ai eu l’occasion de faire tout récemment, est très intéressant, l’objectif est de … Sa stratégie de recyclage de test pour décomposer l’algo en baby steps est vraiment intéressant Dabord Assert.AreEqual("AB", Diamond.Create('B')); // B_should_give_character_sequence() puis Assert.AreEqual("ABB", Diamond.Create('B')); // public void B_should_repeat_characters() Puis Assert.AreEqual("A\nBB\n", Diamond.Create('B')); // B_should_have_separate_lines() Le sudoku est une autre paire de manches… Il faut être honnête, au « moment » où vous devez coder l’algo, il devient très difficile -impossible en ce qui me concerne- de conserver des babys steps. Après moi ça ne me dérange pas plus que ça. Le TDD m’aide déjà suffisamment pour me lancer et coder toute l’infrastructure nécessaire pour le sudoku (coder les règles, le parsing des colonnes, lignes et régions…). On a un débat sur le sujet avec Bruno, il va nous falloir tenter de le faire ensemble pour vraiment voir si les petits test Un autre exemple d’algo pas vraiment possible à coder en TDD: le quick sort… (le bubble sort : ok, mais le quick sort…) Source: https://cdn3.iconfinder.com/data/icons/objects-1/100/diamond-512.png Seb Rose: http://claysnow.co.uk/recycling-tests-in-tdd/
- Bruno: Le TDD comprend 4 activités distinctes que le développeur se doit de maîtriser, il peut les travailler indépendamment pour progresser efficacement. Puis, au finale, les pratiquer toutes sans y penser une fois les automatismes acquis.