On projects that already have tests, you'll often encounter tests that are failing. In this video, discover how those should be handled.
- [Instructor] It's very common to inherit a project that has a test suite but when you run those tests you discover some of them are failing. It's important that you get the test suite into a state where all of the tests are passing. This will allow you to trust the test suite when you encounter a failure and you can confidently use it as a tool to help you make improvements to the system. There are a couple of ways that you can handle the situation but before we go over them we need to talk about how we're going to treat the failing test that we encounter on the project. It's going to be unclear how old the tests are and it's very possible the test suite has just been ignored by the previous developers. This mean the tests have very likely gotten out of sync with the production code they are evaluating but the system is very likely still being used or else no one would ask you to work on it. And that means the people who use the system are the ultimate authority on whether or not it's working correctly. So in the event of confusion about which is correct, the test code or the production code, we are going to assume the production code is correct. That assumption is going to inform the choices that we are going to make as we tackle cleaning up the failing tests. So how do we go about cleaning up the failing tests? We tackle each one at a time and for each one we follow a series of steps to determine what to do. First, we check to see if a dependency is causing the problem. The version that you have might be too new and is not compatible with the code that's under test. Explore this scenario in detail, especially if the failure is caused by an exception. Next, make an attempt to fix the failing test. Sometimes the fix is as simple as changing a constant value that's specified in an assertion statement. In these cases it is fairly clear which changes need to be made to get the test passing again so we make changes until the test is passing. If there was no clarity about how to fix the test then we move onto the next step where we simply just delete the failing test. This situation often comes up when working on a code base that has undergone significant architectural changes since the test was originally written. In that case the test is simply too far out of sync with the production code to provide any meaningful value. Deleting the test is the best thing to do in that situation. We repeat those steps for each failing test until we're left with a test suite that contains only passing tests and then we're ready to make improvements to the application with the confidence that any future failures we see in the test suite will be the result of changes that we've made to the production code.
- Assessing the technical debt
- Creating and running a test suite
- Handling failing tests
- Updating dependencies and tools
- Paying down technical debt
- Remaining test driven
- Monitoring code quality