My name is Davide, hello from southern Sweden, and I would like to start telling a little bit about my personal story with - with test driven development. This started when I was a graduate student, and as any graduate student, I had some side projects I was working on, mainly using Ruby on Rails. And if you're familiar with the framework and the community behind that framework, this is kind of the community that swears - and it's devout to unit testing - and specifically to test-driven development. Also the same time I was deciding about the topic for my dissertation, and I found it interesting to study something that the practitioner community came up - with something that they invented, and then adopted, rather than coming up with something academic and that maybe you - no one will ever end up using in practice. And, let's start with one of the hidden costs, perhaps, maybe false advertisement of what test-driven development is. This is usually how TDD is presented to you: it's a simple, iterative, three-step process. We have a red and green phase that kind of map on the colors of the test frameworks usually used to indicate failing or passing the test suite. We start by writing a failing test case, so, we are in the so-called red phase, and then we move on to the green phase by writing enough code to make the test pass. Then we have an additional blue phase where we can refactor, and the cycle continues by adding new new failing test cases and so on.
In reality I believe that that's an oversimplification, and actually honestly a misconception of what TDD is. In fact it looks a bit more like this: There's two distinct phases with different function: One driven by unit test cases as contracts that you need to fulfill where a lot of things can go wrong. You need to backtrack, you need to make changes to test cases, you need to fight against your desire to write more test code than actually necessary just because you know you're going to write it eventually anyways. And then there's a second part where you try to align the need of your code, or the need that your code may have, with the design, and usually we call this refactor. And this brings its own set of complications. So for example depending on the refactoring you may need to align your old test cases with the new code design, you might need to fix some regression bugs that you you cause during refactoring... Another important decision is actually for the developer to decide when they are satisfied with the quality of the code so that they can move on to the next TDD cycle.
And so here my first hidden cost is that TDD may not be as simple as it seemed. And when looking at the real - looking at the real complexity of TDD I kind of felt, like, okay, why would anybody do that? And I turn out - it turned out I wasn't alone, there are other researchers that have looked into how steep is the TDD learning curve, how much of an overhead it's perceived to be, how it leads the developer to actually focus on happy tests rather than testing sad paths, and all this claim collided with the benefits, or the claimed benefits of TDD, so the fact that test driven development improves design, leads to lower defects, improves developers' productivity as developers now can rely on this extensive safety net made of unit test.
So for us, this kind of begged the question, "Are developers who claim to do TDD actually doing it?" So we performed a study with professional developers that were trained on TDD and asked them to add new features to a legacy system. Now this system is a real-world system, not the kata kind of exercise that people usually employ to practice test-driven development, and has a full-fledged architecture, dependency on external APIs, complicated XML parsing, and so on. Plus, we instrumented the developers IDEs with a plug-in which collects activities happening in the IDE itself, and which we could eventually map into the TDD activities and into TDD phases. And we started looking the results and this is what we get. Here i'm showing just an example of how different the different activities are supposed to be in a TDD fashion. Each activity has a type and a duration, so for example here you can see that this person started with implementing tests first, shown in yellow, then he moved on to adding test cases without the counterpart production code in orange, and then there was a lapse, and this person switched for roughly half an hour to a test-last kind of approach shown in red. And then he added more cycles - he continued developing using test first and doing refactoring which are showing in light blue only at the end.
And so we put all these measurements together, hours of development from more than 60 professional developers, and run this data through some statistical model and what did we learn? Well we observed that the major benefit of doing test driven development is, so the only things, or the things that counts, that explains the perceived benefits or the claim benefits of TDD, like whether code quality as well as productivity, well that thing is not the rigid, religious adherence to test driven development cycle, but rather how fine-grained are the activities in the process. So the fact that each activity such as writing code and writing tests, or the other way around, even, writing testing code and then refactoring, are kept within a short and consistent time interval. So that's the secret sauce of TDD. And notice that this granularity is a by-product of test driven development: it's not enforced by it. It's recommended to keep the cycle short - within five to ten minutes - although we observe that very few people do that, especially in the case of legacy code. And importantly this rhythm of TDD is directly impacted by the scope of the test cases defined to initiate each cycle. So one suggestion here is to be really conscious on the scope of the test case - it's really working in baby steps that's what helps. So, we have now, we now know that you can benefit from TDD, although not directly because of this test first approach but rather because it makes more compelling to write small unit tests.
Finally another aspect we have started and that I actually found quite interesting was to understand how developers actually are enjoying the TDD as a process. Here on the one hand we have existing knowledge, existing literature in software engineering that tells us that happy developers are better at problem solving. And on the other hand we have this: a typical different way of developing software where unit tests kind of control and guide developers' decisions. So we conducted a small experiment this time with students, novices and TDD developers, comparing comparing them to non-TDD developers, and we asked them to perform a series of development tasks, but also asked them to report their perceived emotional state using this pictorial mannequin here called Sam. Basically they could mark on the mannequin what corresponds to their states such as happiness, excitement, frustration, boredom, etc. And here we observe another hidden cost of test driven development: we observe that TDDrs are not as happy as other developers. And when investigating this, we find out that the reason is that TDD forces programmers into this mind-numbing cycle that actually clips their creative wings, and especially in the case of novices, they are just uncomfortable with the TDD counter-intuitive test them right production code kind of thinking. So this is my third takeaway here, so yes, although TDD is not as simple as it might seem, it works if you follow baby step, but nonetheless it comes with an emotional cost which - which you should be aware of.
And that's really all I have for you today. Thank you, you can of course approach me and ask me more and connect with me this is my email and my Twitter handle. Thank you for your time.