Contract Testing Vs Integration Testing

A unit test is at the lowest level. It provides a foundational quality gate.

It's a way of testing a piece of code that can be logically isolated in a system that works as expected.

What constitutes a unit is ill-defined. It often refers to the testing of a single function, but can be broader than that.

The goal of unit testing is to deliver relevant information about the smallest components of your software quickly and frequently, sometimes many times per day.

It's a key practice in TDD (test-driven development). It’s crucial in the ability to refactor (change) code safely, and therefore supports the long-term maintenance of a system.

Unit tests also provide important visibility to new contributors to a code base, because they double as a form of living documentation.

With unit testing, you can isolate and test small components of code at a time.

By limiting the scope of the exercised software to a portion of the system under test, you improve the quality at a foundational level.

Unit testing an API endpoint is normally done by mocking other components or systems, in order to isolate the part of the API you are focused on testing.

A unit test focuses on a small amount of code, such as a single function.

Pre-commit, during build

Developers

Unit tests are extremely fast.

They detect issues earlier to avoid the costs of fixing later in the SDLC.

They’re an efficient means of testing, as it can be done at any time. There’s no reliance on others.

Unit tests focus on individual functionality

They understand the impact of development changes with ease

They assist with code refactoring and reduce long-term maintenance costs.

Unit testing does not do any of the following:

Consider integration issues between services.

Catch complex errors that arise from multiple services.

Consider non-functional aspects, including usability and performance.

Provide guarantees for functional operation or compliance with requirements.

Additionally, unit testing of private/internal functions instead of externally visible functions can lead to a higher maintenance cost. Some schools of thought encourage more “integration test” (sociable) unit tests, which test externally visible behaviour, rather than internal implementation details.

Unit testing is known as a white box testing technique where are you are aware of the underlying structure and code.

There are different unit testing frameworks, depending on the type of code you're working with.

A contract test is a technique for testing software application interfaces and integrations.

Contract testing is a non-functional technique that bridges the gap between unit and integration tests. It takes the benefits of each and ensures two systems communicate.

It's non-functional, because it doesn’t consider side effects.

The goal of contract testing is to get fast feedback on systems that communicate over APIs, removing unnecessary bugs.

Contract testing helps remove the dependency on end-to-end integration tests and reduces the need to maintain complex test environments.

Contract testing ensures that a pair of applications will work together correctly. It checks each application in isolation to ensure the messages it sends or receives conforms to a shared understanding. This is documented in a “contract.”

See how it works.

Similar to a unit test, a contract test focuses on the external collaborator. This is the API client interface on a consumer side, and the appropriate receiver on the provider side, such as a Controller.

Pre-commit, during build

Can also occur post-commit.

During the build: Developers/SDETs

Post-commit: QA/Testers/SDETS

Bi-Directional Contract Testing gives team members without access to the source code a way to orchestrate contract testing, repurposing existing mocks from other commonly used tools.

Contract tests are fast.

They focus on testing a single integration at a time without the need to deploy

With contract tests, there’s no need for dedicated test environments

They provide fast, reliable feedback, that is easier to debug..

Tests scale linearly with the number of integrations, instead of exponentially.

They allow you to deploy services independently.

There’s reduced communication and coordination.

The provider knows who the consumers are and how the consumers use.

Read: "Proving E2E Tests are a Scam"

A contract test is completed in isolation, between only one API consumer and one provider. It doesn't check for side effects, or the behavior of the overall system.

For example, imagine an endpoint for a collection of /orders that accepts a POST request to create a new order. A contract test ensures the consumer and provider have a shared and accurate understanding of the request and response required to create an order. A functional test for the provider would ensure that when a given request was made, an Order with the correct attributes persisted in the datastore. Contract testing is known as a white box testing technique where are you are aware of the underlying structure and code.

PactFlow is the complete contract testing solution. It allows teams to orchestrate contract testing at scale.

With PactFlow, teams get fast and reliable feedback on the reliability of a single integration between an API provider and consumer earlier in the software development lifecycle. This reduces the reliance on complex E2E tests.

Create a free PactFlow account to get started

Integration Test

Integration tests look for information on how two or more systems work together.

They’re a form of functional testing that ensures all features continue to work as expected after a change has been introduced.

Integration testing is the most often used form of API testing, as APIs are at the centre of most integrations between internal or third-party services.

Integration testing catches a class of issues that unit tests can’t pick up – bugs that lurk between components.

The goal of integration testing is to consider the bigger picture and prevent regressions at a higher level; how the features work together to make a product, and how that product will work with other software.

Unlike unit tests, which cover how an individual component works in isolation, integration tests must consider multiple components working together.

An integration test usually consists of many requests or steps that simulate real user behavior. At each step, assertions check that the service works as expected and returns the required response.

Note that “integration testing” is a vague term, encompassing anything from sociable unit tests that span multiple components or functions in a single code base, to real-life systems interacting in a deployed environment.

Integration tests look at how two components work together independently of the system as a whole, to accomplish a specific task or deliver a specific outcome.

An integration test can span multiple functions, classes, components, or even systems.

Pre-commit, during build, after build in deployment environment

Devs and QA/Testers

Integration tests ensure two or more modules work together and can deliver the desired outcome aligned to requirements

They lay the foundations for the next stage of testing.

Integration tests can be difficult to perform compared to unit and contract testing approaches, which are more black box style.

It's time-consuming and resource intensive to test all connected modules of a system.

Additional effort is required to create stubs and drivers, and this needs to be done accurately to avoid ineffective testing.

ReadyAPI allows teams to create, manage, and execute automated functional, security, and performance tests in one centralized interface. This accelerates API quality for Agile and DevOps software teams. Get started by importing API definitions like OpenAPI/Swagger or AsyncAPI, testing and recording live API traffic, or virtualizing web services to remove pipeline dependencies.

Learn more about ReadyAPI

End-to-end test

End-to-end tests are a functional testing methodology. They test the entire functionality and performance of an application under production-like circumstances and data to replicate live settings.

End-to-end tests are valuable, but are the most complicated tests to set up and maintain.

There are two main types of E2E tests:

E2E UI (frontend) / UI)

E2E API tests – also called E2E tests – consider the integrity of the entire system.

E2E UI testing extends end-to-end testing, with the addition of testing behavior through a user interface such as a mobile application or web interface.

The goal of end-to-end testing is to ensure the entire software application is production-ready and avoid risks post-release.

UI testing ensures the end user’s experience is delivered as expected

An API E2E testing process simulates a real user scenario.

This not only validates the system under test, but ensures its sub-systems work and behave as expected.

End-to-end tests extend integration testing to test multiple applications at once, usually deployed to a test environment.

As with the API E2E test, a E2E UI test specifically considers the frontend user experience.

The entire system (excluding the UI).

A UI test considers all components that make up the end user’s experience.

Post-commit, after deployment into a test environment

Testers/QA/ Automation Engineers

All forms of E2E testing are normally conducted by testers to ensure software is production ready. This avoids risks post-release.

The main benefit of E2E testing is ensuring that the whole system and subsystems work as intended. You can catch potential user experience issues from the connected systems.

This confirms your application is functional at every level – from the front to back-end and on multiple systems – and provides perspective on its performance across different environments.

E2E testing also provides expanded test coverage by creating additional test cases that may have not previously been considered.

It detects bugs and increases application productivity.

Read more

E2E tests of any form can be slow. This creates bottlenecks, especially when there are too many E2E tests.

They can also be fragile, due to fluctuating data, wrong versions of code, or wrong configurations.

They can be challenging and time consuming to debug, and require complex environment and data management.

They can make it difficult to assess coverage.

And they come with an expensive overhead – coordinating large all-in-one deployments. With E2E tests, most of the cost is in maintenance, which is why there are the least number of UI tests, with a focus on covering the most crucial workflows.

The impact of this:

• Teams can be left idly waiting
• Tests result in sequential flows
• Testing may result in Late Go/No-Go decisions

For UI E2E testing, TestComplete from SmartBear is a UI functional test automation platform for web, desktop, and mobile applications. You can script your tests or use the scriptless record and replay function.

Learn more about TestComplete