The Build Better Software Podcast

Should your team adopt Test Driven Development?


Listen Later

Show Notes

https://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 s...

...more
View all episodesView all episodes
Download on the App Store

The Build Better Software PodcastBy George Stocker