Introduction to TDD in Spring Boot

- [Instructor] Let's start with the basics. What is TDD? TDD stands for Test Driven Development. In short, this means that instead of first writing the code that does the thing that you want your code to do, you're writing the test to test that code. Clearly, the test will and should fail, because the feature isn't there yet. So after writing the test, you write the implementation of the feature you are working on. And then, if the tests pass, you're done working on the feature. You then go in and refactor your code a bit. And done. It might sound a bit counterintuitive. I remember hearing about this for the first time and thinking, "Okay, sure, but what's that TDD hype about?" So if that's you, let's talk about it, because I changed my mind when giving it more thought and trying it. There are quite some benefits to taking this approach. I actually won't go over all of them, but just touch upon them briefly. The main benefit of TDD is that it helps you write better code. Why? Well, because in order to be able to test it well, you will focus on simpler and decoupled implementations. Also, there's no way you'll run out of time to write the tests, so you'll have a high enough test coverage. Managers and the like might try to push you to move to production when the implementation code is done, but the test code is not. The other way around will not happen. And testing is of incredible importance for having solid code and detecting errors early. Next to these advantages, you'll think better about the feature that you're writing when you start thinking about how to test it. And in the long run, this keeps you a lot more focused on the requirements. So it's fair to say TDD prevents the famous feature creep. Feature creep is when you start adding more and more features that are actually beyond the requirements. TDD requires a very incremental approach to development, which aligns well with the Agile practices. The list goes on and on, really. But in short, TDD leads to higher quality software with fewer bugs because testable code demands decoupled simple code. It's a better experience for the developer because the confidence of the product and satisfaction of the work produced is higher. And it's also great for the business value because requirements are considered better. An important concept of TDD is the red-green refactor cycle. I'm not talking about traffic lights here. The red-green refactor cycle is the simple iterative process of writing your code. The red phase is when you're writing the failing test. Remember, it fails because the implementation code is not there. It is called red because that's a common practice of testing frameworks. They indicate failing tests in red. By writing the failing test, you're actually setting a goal. When this test passes, my code is successful. The green phase is when you are writing the minimal amount of code required to make the failing test pass. Don't overthink it. Don't add an extra functionality that's not required for the test. Just the minimum amount of functionality to make the test pass. And no, I don't mean just return the value your test is checking for. Actual implementation, but keep it to minimum. Resist the urge to write code that handles all sorts of scenarios. And that might sound easier than it is. I know, at least for me, it's not easy. Feature creep is a thing. So why is this called green again? It's a convention of many test frameworks to display succeeding tests as green. And that's what we're going for. Making our tests pass. Next is the refactor phase. You might think you're done when the test succeeds, but not quite. Now let's clean up the code you've written. We've written the minimal code to pass the test. Let's make sure to remove any duplicates, simplify the logic where possible, and enhance the readability. For example, you can improve variable names, extract methods, and even split up lines if one line is too difficult to understand. And if possible, optimize the performance of the code too. Yes, it's a cycle. So let's go back to red and add another failing test, and let's keep going. We can use TDD for any programming language and type of applications. Whether it's a web app, a mobile app, API, whatever sort of system, doesn't matter if it's Java, C#, Python, JavaScript, or any other language. If you can write tests for it, you can develop using the TDD style. In this course, we'll be using it to develop a simple Spring Boot API for task management. And we'll use TDD to develop the different layers of the application. We're going to use JUnit and Mockito for the testing. Let's start setting up our environment.