Tests are essential for any application. They ensure that the changes we make during the app’s development process don’t break existing capabilities (or at least they make errors less likely) and also serve as documentation. Many developers (unfortunately) disregard tests because they are not directly part of the app’s business logic, and, of course, it takes some time to write them. Because of this, tests seem to not have a significant impact. Indeed, their impact is not usually visible in the short term, but trust me, tests are invaluable in the long term. I can’t stress enough how important it is to make sure you properly test your app’s logic.

Why should you write a test instead of relying on manually testing a capability?

• Because you can run that test over and over again to validate things are working as expected with minimum effort (validates the app behaves correctly continuously)
• Because by reading the test steps you can easily understand the use-case purpose (serves as documentation)
• Because tests provide early feedback about new application issues during the development process

Why wouldn’t the app’s capabilities work a second time if they initially worked?

• Because we continuously change the app’s source code to fix bugs or add new features. When you change the source code, you might break previously implemented capabilities.

Writing correctly implemented tests

We write tests to validate the logic implemented by a specific method in the project works in the desired way. When you test a given method, usually you need to validate multiple scenarios (ways in which the app behaves depending on different inputs). For each scenario, you write a test method in a test class. In a Maven project (such as the examples we implemented throughout the book), you write the test classes in the project’s test folder:

A test class should focus only on a particular method whose logic you test. Even simple logic generates various scenarios. For each scenario, you’ll write a method in the test class that validates that specific case.

The test scenario implementation is strongly related to how the app should work, but technically, the idea is the same in any app: you identify the test scenarios, and you write a test method for each:

Implementing tests in Spring apps

We’ll demonstrate each technique by considering a use case we implemented in the previous chapters and write the tests for it. These techniques are (in my perspective) a must-know for any developer:

• Writing unit tests to validate a method’s logic. The unit tests are short, fast to execute, and focus on only one flow. These tests are a way to focus on validating a small piece of logic by eliminating all the dependencies.
• Writing Spring integration tests to validate a method’s logic and its integration with specific capabilities the framework provides. These tests help you make sure your app’s capabilities still work when you upgrade dependencies.

Implementing unit tests

Unit tests are methods that call a certain use case in specific conditions to validate behavior. The unit test method defines the conditions in which the use case executes and validates the behavior defined by the app’s requirements. They eliminate all the dependencies of the capability they test, covering only a specific, isolated piece of logic.

Unit tests are valuable because when one fails, you know something is wrong with a particular piece of code, and you’re shown exactly where you need to correct it. A unit test is like one of your car’s dashboard indicators. If you try starting your car and it fails to start, it might be because you ran out of gas or your battery isn’t working properly. A car is a complex system (same as an app), and you have no clue what the problem is unless you have an indicator. If the car’s indicator shows you’re out of gas, then you immediately identified the problem!