Software testing is a set of techniques that allow us to ensure the quality of the product that we are developing in its life cycle different stages.

Although they have an extra development and maintenance cost, they are especially useful to facilitate software quality in the medium and long term. The type and number of tests must be consistent with the product we are developing: a large product is not the same as a web application to record tasks.

All software should have some type of testing to ensure its quality, regardless of its size or the number of people involved in its development.

Assuming the great variety and quantity of tests that exist when developing software, it is easy for companies and programmers to be confused about which are essential.

However, software testing companies usually believe that the developers they work with should at least perform 3 types of tests on the code: unit, integration and functional testing. Let's take a look at these three to see what they are, why software testing firms consider them essential and what they imply for developers.

Unit tests are all those tests that only check a single-class specific functionality. This type of test "doesn't care" about the behavior of the rest, since most times they receive an object that simulates the external behavior of that class. The ultimate purpose of unit tests is to check very specific functionalities within a specific class.

These are tests that should not take us more than 5 minutes to write, and we should perform as many as needed to test 100% (or close to it) of a code´s possible cases. For example, checking that a method delivers an exception on a given condition is a clear case of unit testing.

This type of test is expected to be very fast to execute, since in a large project there will usually be hundreds (or even thousands!) of these. Without going any further, the Moq simulation framework has 2,843 unit tests, and each one takes only milliseconds to execute.

Then, integration tests are those that verify that the existing relationships between the different classes and services work correctly. They aim to find all those problems that arise when mixing the different layers of an application.

For example, if we work with a database, in an integration test we will use a real database engine and not an in-memory or simulated one. In this way we will validate the correct integration of the system with that database. They are usually more expensive to develop and execute than unit tests, since in each one several points of the system must be integrated to ensure that they work correctly together.

The third category is functional tests, which verify the overall behavior of a system to ensure that the full functionality is met. They are also often called E2E or End-To-End tests. This type of testing is done taking into consideration the performance requirements, and does not focus on the system´s details, which should have already been tested with the two previous groups.

In general, these are tests that require more effort than the previous ones, since we must test the complete system operation based on the existing requirements. This is why we must use the same type of systems that the code will use in production. In addition, it is common for specific tests to be carried out to evaluate performance and verify that it is within the desired parameters.

Relationship Between Test Types

When developing the different groups of tests, as in almost everything, we must apply common sense to test as much code as possible with the least effort. In this sense, it is highly useful to hire a professional software testing company.

For example, it does not always make much sense to try to cover 100% of the possibilities of a specific class with functional tests. The reason is that, in addition to the fact that many times it is not even possible, doing so would greatly increase costs.

In relation to what the amount of code to test should be, it is usually represented as a pyramid in
which unit tests are the base, integration tests are in the center, and functional tests are on the top.

This pyramid is called the testing pyramid or Cohn's pyramid (it is attributed to Mike Cohn although its authorship has never been clarified). What it tries to show us is that, although you should use common sense for each case, in general there should always be many more unit tests than integration tests, and many more than functional tests.

In fact, if among functional tests we have user interface tests, we should keep them to a minimum. The reason is that this type of test, although they usually add a lot of value, are very expensive to create, but above all, they are very expensive to maintain and should not be abused.