Software Quality Assurance & Testing Stack Exchange is a question and answer site for software quality control experts, automation engineers, and software testers. It only takes a minute to sign up.
Sign up to join this community
Well, integration testing supposed to be the testing of integrated components.
Contract testing supposed to be testing of the way components interact with each other (API).
But what the main difference? It seems to be the same thing! Well, okay, are checking two integrated components, example. Anyway, we make them interact with each other. But they interact via API. So, what is the difference?
Martin Fowler has a good article just about that
Quoting him:
Integration tests collect modules together and test them as a subsystem in order to verify that they collaborate as intended to achieve some larger piece of behavior.
While:
Whenever some consumer couples to the interface of a component to make use of its behavior, a contract is formed between them. This contract consists of expectations of input and output data structures, side effects and performance and concurrency characteristics.
When the components involved are micro services, the interface is the public API exposed by each service. The maintainers of each consuming service write an independent test suite that verifies only those aspects of the producing service that are in use
These tests are not component tests. They do not test the behavior of the service deeply but that the inputs and outputs of service calls contain required attributes and that response latency and throughput are within acceptable limits.
To summarize it, integrations tests are about functionality while contract tests are about the interface, or the "language" the two sides speak.
PACT (a common contract testing framework) also have a good explanation to why Contract Tests are not Functional Tests from their point of view:
Contract tests focus on the messages that flow between a consumer and provider, while functional tests also ensure that the correct side effects have occurred.
The term "Integration checking" are usually misused.
Rainsberger has a seminal post called Integrated Tests are a Scam. By "Integrated" he means what is usually called "integration; he uses integration as @Reijmersdal did: If things can connect together.
Contract checking is, here, a type of integration checking. It's about checking if the syntax the interfaces of two components match - no semantic validation happens here: Because well-uncoupled components shouldn't care about correctness in the behavior of external components, only if they can connect correctly.
Think about this as building a lego structure:
The problem with integrated checking is that the number of possibilities grows necessarily asymptotically exponentially to the number of pieces. Unit / Component grows linearly to the number of pieces. Contract checking may grow as integrated does, but that's highly unlikable because each piece will probably connect to just a handful of other pieces.
For me integration testing means testing how multiple microservices integrate to eachother and facilitate a user-workflow. With the goal of finding configuration and wiring issues.
For me contract testing means testing a single microservice API. Testing inputs and outputs of a single service to see if it meets its documented contract. This could be using a mocked storage and a fake consumer or provider. Now I could test a consumer and its provider seperatly and verify they stick to their contracts. This means they "should" work together.
Contract-based test suites are combined to cover each interaction scenario that takes place between the consumer and provider endpoints
...
Contract-based tests typically won't detect endpoint configuration issues or misused classes.
https://techbeacon.com/app-dev-testing/end-end-vs-contract-based-testing-how-choose
Problem with terminolgy is that it could mean something different in different context, different teams, different companies, different industries.
Other reads: https://martinfowler.com/bliki/ContractTest.html
