What’s a Unit Test? Integration Test? E2E Test?

What’s a Unit Test? Integration Test? E2E Test?

Classicist vs Mockist interpretations?

What’s a unit, interface & implementation?

1. UNIT TESTING

1a. What’s a unit?

– Classicist TDD: A module (consists of one or more classes). The module represents a unit of BEHAVIOUR.
– Mockist TDD: A class. The class is the smallest unit of CODE STRUCTURE.

1b. What’s the unit’s interface (contract)?

– Classicist TDD: Publicly accessible classes & methods which are exposed by the module.
– Mockist TDD: Publicly accessible methods of the class.

1c. What’s the unit’s implementation (implementation details)?

– Classicist TDD: Classes that are used internally within the module but are not publicly accessible outside the module.
– Mockist TDD: Code which is behind the public methods. Encapsulation principle.

1d. What’s a unit test?

– Classicist TDD: Sociable unit tests (coarse-grained tests). The unit test is testing the SUT (the module) via the module’s interface with only SOME collaborators (the shared dependencies – e.g. DB, files).
– Mockist TDD: Solitary unit tests (fine-grained tests). The unit test is testing the SUT (the class) via the class’s interface and testing interactions with ALL collaborators.

1e. What are we verifying?

– Classical TDD: State/result verification. We verify the state of the module and/or its collaborators matches the expected state.
– Mockist TDD: Behaviour/interaction verification. We verify that interaction between the class and its collaborators is as expected, i.e. testing message passing between objects.

1f. Where are test doubles used?

– Classicist TDD: Minimal usage of test doubles. Test doubles are used ONLY for the module’s collaborators which are shared dependencies – e.g. database, file system, network, time. Real instances are used for the OTHER collaborators (i.e. non-shared dependencies), no test doubles for them.
– Mockist TDD: heavy usage of test doubles. Test doubles are used for ALL the class’s collaborators.

1g. What kind of test doubles are we using?

– Classicist TDD: Can use any test double (though generally, the preference is towards stubs/spies/fakes and less towards mocks).
– Mockist TDD: Use mocks as test doubles.

1h. How much up-front design?

– Classicist TDD: Minimal. Design emerges later, through refactoring.
– Mockist TDD: CRC cards.

2: INTEGRATION TESTING

2a. What’s an integration test?
– Classicist TDD: Testing integration with real implementations of shared dependencies (e.g. DB, files, network).
– Mockist TDD: Testing integration of classes with real implementations of all their collaborators.

3: E2E TESTING

3a. What’s an E2E test?
– Testing the entire system with real instances of all dependencies. All subsystems are connected. Mirrors the usage of the system from the end-user perspective.