Based on your provided snip timestamps , the podcast episode contains many other insights not included in your snips. Here are a few examples:
Misconceptions about testing: The speakers discuss common misconceptions about software testing, such as the belief that it's difficult to get started or that 100% code coverage is necessary. They also address the overuse of mocking in tests, suggesting it might indicate design flaws.
Building a quality culture: The podcast discusses the importance of integrating QA with development teams, fostering self-empowerment within teams, and adopting continuous process improvement ⟮CPI⟯. The concept of "zero tolerance for defects" is highlighted, emphasizing the need to fix the root causes of defects rather than just addressing the symptoms.
Strategies for Legacy Systems: Advice is given on integrating quality practices into legacy systems, emphasizing the importance of starting with source control, continuous integration, and gradually introducing automated tests, focusing first on unit tests for easily-testable parts of the code. Refactoring is discussed as a key method to improve testability over time.
Impact of frequent deployments: The positive impact of more frequent deployments on software quality and team morale is discussed, illustrating how a shift from infrequent, stressful deployments to more frequent ones significantly reduces stress and improves overall quality of life for developers.
These are just a few of the numerous insights present in the podcast episode that were not included in your snips.
Transcript:
Steve Smith
Right? Believe it or not, there are some clients out there that aren't using source control, you know, some companies and teams. And occasionally, they come knocking on our door. So the first thing we do is we get them on GitHub, GITs if possible, because that's our best recommendation for that and have some source control. Like now you've got source control, that's table stakes. That's great. Next step is you want to make sure that stuff works on someone else's machine besides yours. And the easiest way to do that is to set up a GitHub action or an Azure DevOps, you know, whatever they're called, pipeline, or TeamCity, or whatever you want to use for your CI server, And build the thing on another machine. That tells you that this thing isn't dependent on some setting in your registry or some dependency that only you have installed. And it goes a long way to making sure you don't have the works on my machine syndrome that a lot of times you run into. Once you have that, your initial CI script is just build the code, then you add build the code and run the tests, right? And ideally, the most important tests to run are your unit tests, because they're going to be the easiest ones to put in your build pipeline, because they don't have any dependencies On anything. So you don't have to say, oh, well, I would put that in the build pipeline, but I need a database and I need a web server and I need this and I need that. Like, no, it's just run your unit tests against your package of your code. That's it. And that should be super trivial to do in your build server. And maybe initially you don't have any tests. That's fine. Now that you have the infrastructure in place where your tests matter, right? I wouldn't lead with tests. And the reason is if one developer decides they're going to write tests and nobody else has bought in and it doesn't have anything to do with their build release cycle, then those tests Are going to break from time to time and no one's going to care except for that one developer. And they might yell and say, hey, you broke the test. Like, nobody cares. It's not their problem. You wanted to write those tests, you go fix them. Whereas if you put it as part of the continuous integration script that is used as a gate before your code deploys to the next environment, now when tests are broken, everybody cares, Right? You got to fix that or else the script isn't going to publish your code to the next step. And so once you have that in place now, testing becomes important to the whole team and everyone can start to get bought into the value of them.
Jeff Doolittle
Unless they go and they comment out the test, but that does happen sometimes. When we get to culture, we'll talk about that. And that's unfortunate, but it does happen. So a little bit more though about I've got a legacy system and I don't have any unit tests. And we want to start testing the system. What would you do to start validating the at least current behavior of the system? So you could start with confidence introducing some of these changes in patterns and in testing. Right.
Steve Smith
Well, there's this idea of a testing pyramid where you have like manual tests and user interface tests and an integration test and then unit test. And the reason it's shaped like that is that you generally want to have more of the things at the base of the pyramid, which in this case is unit tests and fewer of the UI and manual tests. It may be in a legacy system that is not very unit testable. And so you may have, they only have like manual testers and that's it. Maybe they're using Playwright or some other thing to automate some UI tests, right? Take whatever automated tests you can find or quickly write and put those into the build process as soon as you can. And then you will almost certainly be able to find some places where you can do unit tests, right? Pure functions that just rely on their inputs and give you some output as a result are always unit testable. And there's usually a way that you can find some places in the code where you can extract something out and turn it into a pure function, right? Maybe it's that if statement that's like seven lines long and tests a bunch of different random things. Like take that if statement, put it into a pure function that says, you know, if some good name for what that condition really means and put all that other logic in it. And now you can write a whole bunch of unit tests that say, hey, if I have this and that and the other, it should be true. And if I have that and the other, it should be false. Right. Those are your first unit tests. They're like pick the easy things that you can pull out. And then you just kind of grow from there. You want to refactor and we haven't talked about refactoring yet, but you want to refactor that legacy system to make it easier over time to test. And ideally, when you're refactoring, you want to have some tests. And initially, that might just be manual tests or UI tests. But as you progress, you'll start to have a larger and larger suite of unit tests that are helping you. And the thing to remind yourself or the client or the team is that you didn't get here in a day. Usually, you have, you know, many developer years of effort went into building this legacy system with no, you know, idea about tests or code quality even necessarily, right? And so now we're going to start to turn the ship, but it's a big ship and it's not going to turn quickly, right? Or for another metaphor, like if you have neglected your health for, you know, 20 years and now you're overweight and not as fit as you would like, and you decide to go to the gym, like a Week later, you're still going to be pretty much how the last 20 years have put you, right? It's going to take some time to change the direction there. And it's the same for your code base. If your code base is unfit, it's going to take a while for good habits to move it back into a fit course. Yeah.
Jeff Doolittle
I will point out for people just getting started to one of the things I'll often recommend is, especially now with a lot of the advanced CICD and things that you can do, even with GitHub Actions, you can spin up Docker containers to do some of those infrastructural pieces that you need in order for some large scale infrastructure tests to run. And so I just encourage people don't run away from making a legacy system testable, even if it's integration testing, while you need to have a larger quantity of more focused unit oriented Tests, you should s... (Time 0:22:50)
