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