Show Noteshttps://doubleyourproductivity.io Transcript (Powered by otter.ai):
Hi, I'm George Stocker, and welcome to the build better software podcast. Today we're going to talk about whether or not you should adopt test driven development, commonly referred to as TDD. Now, test driven development is not about tests or even about testing or about test coverage. It's weird since the first word is test, but we all know naming is hard. test driven development is a development methodology. Put simply, it's a way for teams to write code and ship software systems reliably and consistently. tvV gives you the confidence that you can deploy at 5pm on a Friday because your tests passed. That's what TDD is. It does masquerade as a testing framework, and because of that, it gets a bad rap. But as I said, it's not about the tests. It's about about what the tests show you about your system. Now in systems that are easy to compose, testing is easy. But in systems where a component relies on another component, and they're tightly coupled together, testing is not so easy. Now that's a smell, that's a sign. And what TDV does is it shows you that smell or that sign early, so that you can avoid the problems that will inherently come from parts of your system being coupled together. And that's what it is for developers for a business. test driven development is a way of being able to develop software with confidence to produce software that can be shipped reliably and consistently, without regression bugs, and without deadlines slipping now I'm not talking about that full confidence of a white dude in tech. We've all seen that I'm talking about that quiet confidence that's usually disquieting and reassuring, at the same time, confidence of a system administrator that regularly checks their backups. Regression bugs can become a thing of the past. And even do developers can work on a code base with confidence, talking about that kind of confidence. Also for a business, it allows them to respond to change more quickly. Now, what do I mean by that? Your team has been given a new vertical to approach to develop a feature for and you don't know much about it. test driven development allows you to break down the problem to specify what the code is going to do in the customers language. And test driven development allows you to talk to your business or your customer in their language, and that's really important. Now, let's talk about a little bit about what test driven development is. What do you do Historically, there have been three rules of TDD, although that's itself a misnomer. And it briefly goes like this. You write a failing test, you write code that allows that test to pass. And then at regular intervals, you refactor your work. And it sounds simple. I know. And that's been part of the problem with adopting it. You see, there's a lot of detail into failing, test passing, testing and refactoring. You have an architecture and your system that will evolve from this. And that can't rely on just those three simple steps in order to work. So regular inspection of the work that you're doing, changing how you're implementing something, and then looking at an overarching picture. And that's why test driven development by itself won't make your team successful. There aren't any silver bullets in software development, as Fred Brooks once said, and he continues to be right. But test driven development together with other practices can make your team successful under the right circumstances. Now, those circumstances are why we're here today, should your team adopt test driven development to do that? I can't give you any absolutes. There aren't any. I can say that we can look at your context, look at your team, look at your business. Look at how you're set up. And we can go from there. But there are no absolutes and anybody who tells you otherwise. doesn't understand the problems that we face. The first thing that happens when you build systems through test driven development is you have to make sure the test for a given piece of functionality is written first.
Now if you're trying to adopt TDD Establish system that may or may not be an easy thing to do. You may have to set up a lot of dependencies to even get that first failing test to run. And that's assigned your team needs a lot of outside dependencies to run that's going to make adopting TDD in the existing system harder. You can do it, but it's going to incur months pain before you finally see the benefit. And this is, as they say, sub optimal. Adopting TDD for an existing system takes drive and discipline on the part of the development team and your business. Because you're about to run a marathon. If you're in a business or organization that changes too quickly, or doesn't want to work can't invest in work over the course of months and years to get to a better result, may want to rethink adopting TDD for your project or your team. You will endure pain to pass design decisions that coupled implementations together often unwittingly Pain was going to be hard to fix because it requires putting in characterization tests over code that's already written to ensure you don't break it as you're trying to refactor it out into a TDD system. Now, characterization tests are tests that you create over a working system to spell out in test what the system does. It's been merely to show that this is how the system operates. You try not to mock out anything if you can help it, because there's always a chance you'll mock out behavior that you actually needed to be in the test. It is slow and tedious work. Now, it's not all bad news. characterization tests help you to see the system for what it is for what it is and what it requires to work. This is incredibly useful information as you start to adopt test driven development, as it shows here is the system that can easily bring under test alongside parts that will require extra scrutiny since they deal with external actors or hard to configure states in the system. The second factor in determining whether you should adopt TBD is your building deployment pipeline? how mature are your continuous integration and continuous delivery practices ci and CD? How automated are your builds, some member of your team have to manually copy files over from one server to another, or manually run a SQL script. How does this look up your deployment stack? What is it like to deploy software to test or staging or production and TDD part of the value is seeing that the test failed immediately. And while TDD does strive for fast tests, characterization tests may not be fast. After all, they are literally building up parts of your system to run. So you'll want to make sure you have an automated build pipeline before you adopt TDD. Now. Third, TDD is an investment. We say that a lot in tech, but it's really true here. TDD is a way of changing How your team develops software. It is the difference between building houses from experience and building houses from a blueprint. If your team is really good at building houses, they may not need a blueprint, especially if they're building the same house over and over and over again. But if what you're building is a little bit different every time, then it helps to have a blueprint. With tester development. those tests are your blueprint. They keep you in check. They help you make sure that whatever code that you're writing is not tightly coupled to other pieces of code. One of the ways they do that is how your tests are set up. If a test is hard to set up, then that's assignments to coupled with something else. And test driven development shows you that but it still requires some overarching foresight and a larger picture to build from. It doesn't replace upfront architecture or design, one of the problems teams have had in adopting test driven development is they, they somehow believe that those, those things can go away. Now, we don't need upfront architecture, we don't need upfront design. That's just not true. If you don't know where you're trying to go, you'll never get there. But for your business, you have to be sure you're in alignment with them. If you know what the final system is supposed to look like, if you know who it's for and how it's going to be used, then it's easier to build it through TDD. If those are things you don't know, or those things might change rapidly. For instance, you're on a product team, developing software for a new market, or the team has no experience in this market, then TDD may not be the way to go. A prototype might be build a small prototype, get out into the market, and then as you learn, have that second attempt, at second pass at building your system, be done through TDD
Now if you are also in a long term IT team on a long term project or a long term intern product, test driven development may be for you. Some businesses may not want to invest in the time to rewrite their systems. And some businesses may be perfectly fine with that. You can adopt test driven development without rewriting a system, but it's easier to adopt it if you've started it from the beginning. It's a part of the core way that we're building that system. If not, you have to deal with as I said before characterization tests and those can be difficult to work with. But overall, if you want to adopt test driven development or if you think that you should adopt test driven development, there has to be a Why behind a wire that goes beyond we want clean code. No one cares about clean code except the people working in it. And so while TV has that advantage, it will give you to an extent code that's easier to maintain, easier to change and easier to understand. You won't be able to sell it. With those features, you will be able to tell your organization, we can now make changes with confidence. We can now deploy 5pm on Friday. No, you will not have any showstopper bugs or any regression books. The customer will gain confidence with the system because they're not going to get any of those nasty surprises. And that's how you can sell it. Now, why TDD? Why not unit testing? Why not automated testing? Why not automated UI tests? Automated UI tests, end to end tests and unit testing. Those are all tests. Their purpose is to verify something that's already written. Where's the purpose of TDD is to verify how something's supposed to work first. And to allow you to add on to that, without tightly coupling parts of your system together, unit testing, automated testing and indent testing. They don't take that into account. They simply say, Hey, this is what is and we will work within that framework. That makes him much more brittle than test created through test driven development. Because anytime you change how the system works, you're gonna have to change those tests, even if the ending havior is the same. You've probably seen this a lot if you work with automated UI testing. Forms name changes. Suddenly your tests break even though the behavior is still the same, or with an end to end test, you no longer call a specific piece of the system, you no longer add a row to a database. Now your test breaks even though the behavior hasn't changed. And that's the world of testing code. After you've written it. You will always be coupled to those implementations. TDD flips that on its head. You write the test first. You build incrementally against that test, and against more tests, and then you refactor as the tests become hard to write hard to read, or as you see that they are duplicating information. That's where most of the value of TDD is, is in finding ways to change the system without causing problems for your existing suite of tests. Now in a system built through TDD You would still have automated end to end tests, because none of the schools say that you don't need automated and tests. But done well. TDD can reduce the amount for automated end to end testing you need or automated UI testing that you need. But that's going to end up being a team decision, a style decision. If you have the context where you're able to introduce TDD into your team, it's going to be
a method of development that the entire team adopts. If you're not able to do that, not able to say, hey, all of us on this team should use test driven development, then it may not be the development methodology for you. But all of this comes down to one fundamental truth. After 60 years of developing software. We still can't do it reliably and consistently. test driven development helps solve problem. But it requires a commitment from your team, a commitment from your business. And an upfront approach to understanding how your customer thinks, what the system is for and how it's going to be put together. Now, if all that works for you then adopt test driven development. And if it doesn't, don't, there's certainly not a requirement to produce software through TDD, but it will make producing software easier and faster. Well, that's it for today. I'm George Stocker, and thank you for listening to the build better software podcast. Hi, George, again. I also offer courses and corporate training through my website, double your productivity.io. If any of this sounded interesting to you today, and you'd want to see if you should, your team should adopt TDD, send me an email. You can find it on double your productivity.io Thanks