Unit, integration, and coverage tests are crucial to ensure that your software does what it is supposed to do, then, automating the testing process lets developers rest at ease when handing over the project to someone else. This is why it is mandatory to be familiar with these types of tests. Even if there are several other types of tests, knowing about these three types of testing is usually enough to bring a developer’s knowledge toolkit to the next level.
Unit tests
Unit tests comprise the lowest level of testing. As the name suggests, each test confirms the functionality of small, unitary parts of the system. The more specific, the better, but it always depends on time and resource constraints. For example, one might take a registration form and try to write every type of data in each of its fields, expecting a specific response for each type. In most cases, a password field should contain a combination of numbers, letters, and special characters. Is every special character allowed? How long should a password be? Can the user write its username as a password? All of these are questions the test developer should ask itself when writing each unit test.
At first glance, unit testing may seem arduous and useless, but dedicating time to write critical unit tests can make the difference between large, trustworthy, and scalable systems and hellish repositories where no one truly knows if the platform does what it’s supposed to do.
Integration tests
Yet again, the name tells us what we need to know about these types of tests. Integration tests aim to test the interactions of each software component, one against the other. A level higher than unit tests, integration tests are handy in projects where many developers contribute to the code base. Their objective is to ensure that, for example, by upgrading a package dependency, the developers did not break a feature in a completely different part of the system.
Small software projects don’t make much use of integration tests, but larger ones such as open-source projects are impossible without this level of testing.
Coverage testing
Finally, we have coverage testing, a not-so-obvious way of testing your code. While unit and integration tests confirm that each method and class behaves as it should, coverage ensures that the code, conditions, and logical paths are tested thoroughly. Coverage ensures that in an if-else statement, both paths are taken into account during the testing process.
Incorporating tests into your development process
Most developers hate writing tests; they find it tedious and boring. But the minority who do enjoy it know that tests can help them code faster. It is not unusual for code to break during development, even for the shrewdest developer. Writing tests as you design new features can help you avoid having to fall back to see where you messed up the business logic. Furthermore, higher-level tests can be written even by product owners and managers, which helps ensure quality and improves the project’s overall health.
Start small. A single test in critical parts of your code can do wonders down the line. They also help future developers know how your code works, as tests aim to mimic production behavior. No documentation? Not a problem if there are tests. No tests? Not even the prettiest documentation can save you there, and may the force be with the developer tasked to develop a new feature without breaking another in an untested system. A famous saying in software development is “if it’s not tested, it’s broken. (Bruce Ecke)”.
Source: http://softwaretestingfundamentals.com
