What is a Test Coverage

Idea of test coverage is to give you confidence while quickly verifying whether the change will break things.

Different Types of Tests

Unit test

Tests a single unit in isolation.

• a class
• A unit test will create an object, invoke a method, and check a result
• It answers the question "does my code do what I intended it to do?"

Even if all unit test with 100% coverage do what they are supposed to do, there is no guarantee that the complete system works as designed.

Integration test

Tests the combination of two components in the system

• It is focused on the relationship between the components, not the components themselves
• It answers the question "do these components work together as intended"

System test

Tests the whole software system

• It answers the question "does this software work as intended?"

Acceptance test

Automated way for the customer answer the question "is this software what I think I want?"

• It is kind of a system test

All automated tests are limited by axiom "End-to-end is further than you think" - meaning, eventually a human has to sit down in front of a computer and look at user interface to make sure something is working as expected

Differences

Unit tests are faster and easier to write, faster to run, and easier to diagnose. They don't depend on "external" elements like a file system or a database, so they are much simpler/faster/reliable. Most unit tests continue to work as you refactor (and good unit tests are the only way to refactor safely). They absolutely require that your code be decoupled, which is hard, unless you write the test first. This combination of factors makes the Red/Green/Refactor sequence of TDD work so well.

System tests are hard to write, because they have to go through so much setup to get to a specific situation that you want to test. They are brittle, because any change in the behavior of the software before can affect the sequence leading up to the situation you want to test, even if that behavior isn't relevant to the test. They are dramatically slower than unit tests for similar reasons. Failures can be very difficult to diagnose, both because it can take a long time to get to the point of failure, and because so much software is involved in the failure. In some software, system tests are very difficult to automate.

Integration tests sit in between: they are easier to write, run, and diagnose than system tests, but with broader coverage than unit tests.