Unit tests are very low level and close to the source of an application
They consist in testing individual methods and functions of the classes, components, or modules used by your software
Unit tests are generally quite cheap to automate and can run very quickly by a continuous integration server
Integration tests
Integration tests verify that different modules or services used by your application work well together
For example, it can be testing the interaction with the database or making sure that microservices work together as expected
These types of tests are more expensive to run as they require multiple parts of the application to be up and running
Functional tests
Functional tests focus on the business requirements of an application
They only verify the output of an action and do not check the intermediate states of the system when performing that action
The difference between functional and integration tests is that an integration test may simply verify that you can query the
database, while a functional test would expect to get a specific value from the database as defined by the product requirements
Acceptance testing
Acceptance tests are formal tests that verify a system satisfies business requirements. They require the entire application to be running while testing and focus on replicating user behaviors
But they can also go further and measure performance of the system and reject changes if certain goals are not met
Performance testing
Performance tests evaluate how a system performs under a particular workload
These tests help to measure the reliability, speed, scalability, and responsiveness of an application
For instance, a performance test can observe the response times when executing a high number of requests, or determine how a system behaves with a significant amount of data
Smoke testing
Smoke tests are basic tests that check the basic functionality of an application. They are meant to be quick to execute, and their goal is to give you the assurance that a major feature of your system are working as expected
Smoke tests can be useful right after a new build is made to decide whether or not you can run more expensive tests, or right after a deployment to make sure that they application is running properly in the newly deployed environment
Mock object
Mock objects are simulated objects that mimic the behavior of real objects in controlled ways, most often as part of a software testing initiative
In a unit test, mock objects can simulate the behavior of complex, real objects and are therefore useful when a real object is impractical or impossible to incorporate into a unit test.
If an object has any of the following characteristics, it may be useful to use a mock object in its place:
The object supplies non-deterministic results (e.g. the current time or the current temperature);
It has states that are difficult to create or reproduce (e.g. a network error);
It is slow (e.g. a complete database, which would have to be prepared before the test);
It does not yet exist or may change behavior;
It would have to include information and methods exclusively for testing purposes (and not for its actual task)
For example, an alarm clock program which causes a bell to ring at a certain time might get the current time from a time service. To test this, the test must wait until the alarm time to know whether it has rung the bell correctly. If a mock time service is used in place of the real time service, it can be programmed to provide the bell-ringing time (or any other time) regardless of the real time, so that the alarm clock program can be tested in isolation.
Mock objects have the same interface as the real objects they mimic, allowing a client object to remain unaware of whether it is using a real object or a mock object