Why Hasn't TDD Taken Over The World?

during the course of my career as a software developer there have been several times when an idea has come along where I thought this is going to change everything sometimes I was right but sometimes not test driven development was one of those ideas I was a bit skeptical before I actually tried it but as soon as I did try it I thought this is clearly a better way to work and everyone will work this way from now on clearly I was wrong so why hasn't test driven development taken over the world yet here are 10 common to to tddd adoption that developers describe and my responses to [Music] each hi I'm Dave Farley of continuous delivery welcome to my channel if you haven't been here before please do hit subscribe and if you enjoy the content today hit like as well I was first exposed to extreme programming the approach that introduced the world to the rediscovered idea of test room development as well as its Associated practices like continuous integration and pair programming in around 1997 that was very soon after Kent Beck published his book extreme programming explained I had already tried a form of continuous integration though it wasn't called that then a few years before when we created a rolling continuous build for one of the projects that I worked on and that had been very successful for us on that early 90s project we had a handful of smoke tests to validate the basic core functions of the system but it certainly wasn't test driven development when my enthusiastic young teammate said we should do extreme programming a bit later we all laughed and dismissed the idea because of the silly name largely even though we were already taking automated testing pretty seriously on that project and running a continuous integration and build process the testing though was more of the whole system integration style testing the moment when the tdd light bulb went off over my head first started when I saw junit which made unit testing so much simpler and so much more obvious about what we should be focusing on than anything that I had seen or done before I thought at the time this looks like a fantastic idea and we certainly improved our testing on that project by adopting junit but even so the real lesson of test driven development still didn't really land for me properly I treated it rather as a tool in my tool box to occasionally pull out when I thought it was useful rather than as a guiding principle for how I would organize my work which is much closer to what it is today like everyone else I didn't really get the prime directive of test driven development write the test first it just seemed so unnatural and it just made the testing that I already valued much more difficult a few years later though I joined a consultancy called thoughtworks who were very big proponents of test development and extreme programming here I worked with people that really understood tdd a lot better than me and I learned from them this was the time when I really got it and thought this is amazing in the future all code will be built this way again I was still wrong I tell you this story because I think it points out two big barriers to the adoption of test room development quite effectively the first is that it's easy to confuse unit testing with test driven development now I see them as distinctly different things but in my experience everyone makes mistakes uni testing as the important bit at first but I'd argue that in reality it's the other way around everyone starts out thinking okay I get it it's all about having loads of unit tests and amazingly high levels of test coverage but that isn't the goal at all that's a side effect not the goal the real Target is to be able to build better software more easily which is something that you get from test driven development but usually don't from unit testing alone let me pause there and say thanks to to our sponsors we are fortunate to be sponsored by Eco experts tricentis and transic all these companies offer products and services that are extremely well aligned with the topics that we discuss on this channel here every week so if you're looking for excellence in continuous delivery and software engineering click on the links in the description below to check them out the other thing that my story tells us is that this is it extremely helpful to work on a team that already gets it my previous team who first attempted extreme programming we're very skilled very talented group of developers but we all missed the real value of test driven development and so of extreme programming really working with people who already get tdd is by far the best way to learn it in fact I can't think of anyone that I know of that's been through that experience who didn't afterwards prefer test driven development as as their approach my impression is that the people who dislike it have never really tried the real thing thing that sounds like a horribly dismissive thing to say and it's not really very helpful in trying to convince people for sure but I don't really mean to be dismissive but as I have said before in my experience all of the things that people complain about in test room development aren't outcomes of tddd at all they're outcomes of poor unit testing I explain this in more detail in this video I published a question on Twitter a while ago and got a lot of responses my colleague B recently published a LinkedIn post analyzing the responses we got and he found 10 categories of challenge to test driven development adoption that people generally responded with here I'm going to go through those 10 and we'll and talk a little bit about each the first one is the learning curve this is certainly true no one is born with the innate ability to write code and no one is born being able to write code with testm development either this is a skill it takes time to learn but then so is coding I think that the real skill barrier though in tdd is less to do with tdd itself and much more about what it exposes us to so clearly the poor quality of our design choices I think that I can teach you the basics of test room development in a few days but learning to be good at design is the kind of skill that will take take you a lifetime to acquire and more than anything else that I know of test driven development Pres presents you with the costs of your design choices immediately this is one reason that I value it so highly but I think it's one of the reasons that makes it more difficult to adopt in that sense yes test driven development is difficult to learn but the important Point here is that what you are learning is a skill that is absolutely foundational to what it is that we do for a living design so maybe that's worth a bit of investment in time and effort to increase your skills in this vital area which takes us to to the next in the list the investment in time a Common Thread in the responses was that test driven development takes much more time than working without and again there may be some degree of Truth here but once again I would argue that this is something of a misinterpretation of what's really going on there may be a little bit more typing involved sure because we've got to create tests but if that is your limiting factor in software development typing I think that you probably do doing it wrong we need to optimize for thinking not typing if it takes me longer to come up with a better more flexible more readable design I think it's worth it particularly when you factoring what really matters in terms of the time that we spend the overall cost of living with the code that we wrote If testr and development allows me to write code with fewer bugs and makes my code easier to change then that is a good bargain in my opinion third in the list is the lack of Education in test driven development I guess this is fair I said already the best way to learn test driven development is from people who already know it and ideally in your own code base so working alongside people that are already practicing test development but there's a shortage of people with these skills and so that's a difficult way to learn in the absence of having someone to show you how do check out my free test driven development tutorial that's meant to help to get you started there's a link to that in the description below too fourth on the list are cultural factors there is a lot of resistance to trying new things and testam development raises a lot of objections usually from people who have never tried it so this is certainly a barrier my advice is to try it anyway see what you make of it for yourself but you will need to practice a bit you can't tell if you like test Ren development or not in an hour or two it takes longer than that to get it for most people my advice is to commit to completing a simple coding Carter of some kind for 30 minutes every day for 2 weeks after that you'll have a much better idea of whether there is something in it or not check out the the tutorial for examples of that code design and evolution is fifth on the list I wonder if this objection though is one of those symptoms of confusing unit testing after the code with test development the huge win in test in development is when you understand what it is that you're meant to be testing the goal is to assert what you want your code to do not how it does it this is much more natural and easier to do if we write the co the test before we write the code than it is if we add the test later I find test room development makes my code much easier to explore with and I'd say it enhances my ability to design and evolve my solution rather than hampers it next on the list are maintenance challenges there is some extra maintenance we're going to have to maintain the tests as well as the code but the amount is largely down once again to the quality of your design and that is part of the trick and the challenge that test driven development offers to you as I said earlier test driven development gives us the earliest opportunity to get feedback on our design choices if we listen and respond to that feedback we change our code in ways that makes it better in particular makes it more modular and cohesive with better separation of concerns better abstraction between the parts of the code and looser coupling all all around all of these things make the code both more testable and consider considerably easier to change and so maintain so although you may now need to change tests as well as the code when maintaining everything in my experience this is less than changing the worst code that I probably would have written without the tests as ever writing tests first is the key here the tests can't drive better design choices if you don't write them until after you've made your design choices next on the list are the perceived benefits versus short-term costs it's impossible to talk about other people's perceptions sensibly but my impression is that people who think that this this tend to undervalue the benefits that we get from tdd and overvalue the short-term costs the most efficient effective teams that I've ever seen let alone being part of have PR all practiced test driven development you have to remember to factor in the saving in time effort and money of not needing to fix bugs that that don't exist in the code anymore this is hard to evaluate but the state of devops data which measures continuous delivery practices in general but not tdd specifically says that teams that score well on stability and throughput spend 44% more of their time on new features than teams that don't I guess that there's a fairly High correlation between people doing well with continuous delivery and people to practice in test driven development if I'm honest I think that this is more of an excuse and a mistake by by people who don't really want to do test driven development they think that they will spend more time writing tests and less time on the stuff that they like doing designing the solution when in reality the reverse is true the tests are after all part of the design process next in the list are misconceptions and misinterpretations this is less of an objection to test room development and more an observation of the reasons why others reject it which is given the original question a fair yes there are lots of misconceptions and misinterpretations of what tdd is and what it's like to practice so I think that is a barrier the next on the list practicality in specific scenarios there are certainly some times when test development is hard harder than others to apply most of those have to do with IO of one form or another and maybe concurrency but in reality this mostly once again is a matter of design Choice when you buy into test driven development you tend to change to make your designs easier to test and I would argue that the choices that you need to make to achieve that are nearly always to the benefit of the design and quality of the code there isn't a a specific technology nor a a a type of software that I've come across that isn't amable to test driven development in my experience yes you can build uis yes you can build embedded systems yes you can build high performance systems yes you can build safety critical systems all of these situations work last in the list surprised me when I saw it the fear of job security this was the most surprising ENT entry on the list from my point of view and one that I have never seen personally apparently some people have met others who were scared that if they wrote tests for their code they would make their code easier for others to change and so that made them scared of losing their jobs that's a pretty sad State of Affairs and I'm not sure how to react to it my working assumption is that if you write better code then you'd hope that that would at some level be recognized as a good thing and so make your employment more secure not less I guess that this is a kind of backhanded compliment to test driven development it makes my code so easy to change that my job's at risk I don't really have any advice to people working in such dysfunctional organizations other than to say keep an eye out for better places to work it's been my experience that good software developers are hard to find so while not doubting that there are some employers that are so bad that this story may be true I can't really imagine that making my code worse to secure my job is likely to be a good long-term strategy please do check out Bernard's article there's a link in the description to that below too he has more and different things to say about the feedback that we collected thank you very much for watching and if you enjoy our stuff here on the continuous delivery Channel please do consider supporting our work by joining our patreon community also joining the the often Lively conversations in on Discord there thank you again and thanks to all of our patrons for their [Music] support

Channel: Continuous Delivery

Views: 46,963

Keywords: tdd, test driven development, is tdd worth it, how to do tdd, is tdd dead, the prime time, prime reacts, ThePrimeagen, programming, computer, software engineering, software, software development, developer, web design, dave farley, continuous delivery, computer science

Id: XsbMNWW-hdY

Length: 15min 38sec (938 seconds)

Published: Wed Nov 29 2023