Creating unit tests

When we write code, we should test it. No code has ever gone into production before at least doing some test runs. There are different levels of tests having different aims, technologies, industry practices, and names.

Unit tests, as the name suggests, test a unit of code. Integration tests test how the units integrate together. Smoke tests test a limited set of the features just to see that the code is not totally broken. There are other tests, until the final test, which is the proof of the work: user acceptance test. Proof of the pudding is eating it. A code is good if the user accepts it.

Many times, I tell juniors that the name user acceptance test is a bit misleading, because it is not the user who accepts the result of a project, but the customer. By definition, the customer is the person who pays the bill. Professional development is paid; otherwise, it is not professional. The terminology is, however, user acceptance test. It just happens that customers accept the project only if the users can use the program.

When we develop in Java, unit test is testing standalone classes. In other words, in Java development, a unit is a class when we talk about unit tests. To furnish unit tests, we usually use the JUnit library. There are other libraries, such as TestNG, but JUnit is the most widely used, so we will use JUnit. To use it as a library, first, we will have to add it to the Maven POM as a dependency.