About Unit Testing:
• Unit Tests validate the smallest components of the system.
A single class / unit is tested in isolation
• They don't use external resources. Dependencies are mocked if needed
• Unit tests target to cover the basic correctness of the code.
They are usually simple to write. A failed unit test is always a regression
(if the business logic has not changed)
• Running them frequently is critical to detect bugs on the business logic
as early as possible (the team can fix these issues immediately)
• As a best practice Unit Tests run as part of the continuous integration process.
Every code commit triggers an automatic build and unit tests are also compiled - should be a very short cycle
• Unit Test coverage percentage can be measured. As a best practices the development
team can define a threshold for Unit Test coverage (the team can make sure that the
Unit Test coverage does not drop when adding new features)
About Integration Testing:
• Integration Tests validate the integrated software (the entire system or a sub-system)
- individual software modules are integrated logically and tested as a group
• Each integration test should have a test case with clearly defined entry and exit criteria
• No mocking is used (dependencies, infrastructure, environment should be as real as possible)
• Test verifies implementation of individual components and their interconnection
behaviour when they are used together (including the flow & correctness of data between the components)
• A failed integration test can also mean that the code is still correct but the environment has changed
• Integration Tests can run for several hours based on the complexity of the project.
Usually run as part of the nightly build process