Bird
Raised Fist0
Rest APIprogramming~5 mins

Contract testing in Rest API - Cheat Sheet & Quick Revision

Choose your learning style10 modes available
LearnWhyDeepVisualTryChallengeProjectRecallTime
Recall & Review
beginner
What is contract testing in REST APIs?
Contract testing is a way to check that two parts of a system, like a client and a server, agree on how they communicate. It makes sure the API responses and requests match what both expect.
Click to reveal answer
beginner
Why is contract testing important for REST APIs?
It helps catch problems early by verifying that changes in the API or client do not break their communication. This keeps apps working smoothly without surprises.
Click to reveal answer
intermediate
What are the two main types of contract testing?
The two main types are consumer-driven and provider-driven. Consumer-driven means the client defines what it needs. Provider-driven means the server defines what it offers.
Click to reveal answer
intermediate
How does a contract test differ from an end-to-end test?
Contract tests focus only on the agreement between client and server, checking request and response formats. End-to-end tests check the whole system working together, including UI and databases.
Click to reveal answer
beginner
Name a popular tool used for contract testing REST APIs.
One popular tool is Pact. It helps create and verify contracts between API clients and servers easily.
Click to reveal answer
What does contract testing primarily verify in REST APIs?
AThe database schema
BThe agreement on request and response formats between client and server
CThe user interface design
DThe speed of the API response
Which type of contract testing is driven by the client’s needs?
AProvider-driven
BEnd-to-end
CConsumer-driven
DUnit testing
Which tool is commonly used for contract testing REST APIs?
APact
BSelenium
CJest
DPostman
Contract testing helps prevent which of the following?
ABreaking changes between client and server
BSlow internet connection
CUI layout issues
DDatabase indexing problems
How is contract testing different from end-to-end testing?
AThey are the same
BContract testing tests UI; end-to-end tests API
CContract testing is slower than end-to-end testing
DContract testing checks communication agreements; end-to-end tests the full system
Explain what contract testing is and why it is useful in REST API development.
Think about how two friends agree on how to talk to each other.
You got /3 concepts.
    Describe the difference between consumer-driven and provider-driven contract testing.
    Who decides the rules: the client or the server?
    You got /3 concepts.

      Practice

      (1/5)
      1. What is the main purpose of contract testing in REST APIs?
      easy
      A. To check the API's user interface design
      B. To test the speed of the API response
      C. To ensure two systems agree on the data they exchange
      D. To monitor server hardware performance

      Solution

      1. Step 1: Understand contract testing definition

        Contract testing checks if two systems agree on the data format and behavior during communication.

      2. Step 2: Compare options to definition

        Only To ensure two systems agree on the data they exchange matches this purpose; others relate to speed, UI, or hardware, which are unrelated.

      3. Final Answer:

        To ensure two systems agree on the data they exchange -> Option C

      4. Quick Check:

        Contract testing = data agreement [OK]
      Hint: Contract testing checks data agreement between systems [OK]
      Common Mistakes:
      • Confusing contract testing with performance testing
      • Thinking contract testing checks UI or hardware
      • Assuming contract testing is about security
      2. Which of the following is the correct way to define a contract test for a REST API endpoint?
      easy
      A. Test the API's front-end layout on different browsers
      B. Measure the time taken for the API to respond
      C. Verify the API server's CPU usage during requests
      D. Check if the API returns the expected status code and response body

      Solution

      1. Step 1: Identify contract test elements

        Contract tests verify the API response matches the agreed format, including status codes and body content.

      2. Step 2: Match options to contract test definition

        Check if the API returns the expected status code and response body matches this exactly; others relate to performance, server metrics, or UI, which are not contract tests.

      3. Final Answer:

        Check if the API returns the expected status code and response body -> Option D

      4. Quick Check:

        Contract test = expected response check [OK]
      Hint: Contract tests check expected status and response body [OK]
      Common Mistakes:
      • Confusing contract tests with performance or UI tests
      • Ignoring response body content in contract tests
      • Testing server hardware instead of API contract
      3. Given this contract test snippet in JavaScript using Pact: <pre>provider.addInteraction({ state: 'user exists', uponReceiving: 'a request for user data', withRequest: { method: 'GET', path: '/user/123' }, willRespondWith: { status: 200, body: { id: 123, name: 'Alice' } } }); What will happen if the provider returns status 404 instead of 200 during the test?
      medium
      A. The test will pass because the body matches the contract
      B. The test will fail because the status code doesn't match the contract
      C. The test will ignore the status code and only check the path
      D. The test will pass if the response time is fast enough

      Solution

      1. Step 1: Understand the contract test expectation

        The contract expects a 200 status code with a specific body when requesting '/user/123'.

      2. Step 2: Analyze the provider's actual response

        The provider returns 404, which does not match the expected 200 status code.

      3. Final Answer:

        The test will fail because the status code doesn't match the contract -> Option B

      4. Quick Check:

        Status mismatch causes test failure [OK]
      Hint: Mismatch in status code causes contract test failure [OK]
      Common Mistakes:
      • Assuming body match overrides status code mismatch
      • Ignoring status code in contract tests
      • Thinking response time affects contract test result
      4. You wrote a contract test that expects a JSON response with a field email. The test fails because the provider returns emailAddress instead. What is the best way to fix this?
      medium
      A. Change the provider to return email as expected by the contract
      B. Update the contract to expect emailAddress instead of email
      C. Ignore the field mismatch and pass the test anyway
      D. Remove the email field from the contract test

      Solution

      1. Step 1: Identify contract responsibility

        The contract defines the expected data format; the provider must follow it.

      2. Step 2: Choose the correct fix

        Changing the provider to return email matches the contract, ensuring stable integration.

      3. Final Answer:

        Change the provider to return email as expected by the contract -> Option A

      4. Quick Check:

        Provider must match contract fields [OK]
      Hint: Provider must match contract fields exactly [OK]
      Common Mistakes:
      • Ignoring field name mismatches
      • Changing contract to fit provider without agreement
      • Removing important fields from contract
      5. You have two microservices: Service A (consumer) and Service B (provider). Service A expects Service B's API to return a list of products with fields id, name, and price. You want to write a contract test that allows price to be optional (sometimes missing). Which approach best achieves this?
      hard
      A. Define the contract so price is optional using a matcher that allows missing fields
      B. Require price always in the contract and fail if missing
      C. Remove price from the contract entirely
      D. Ignore the contract and test only after deployment

      Solution

      1. Step 1: Understand optional fields in contract testing

        Contract tests can use matchers to allow fields to be optional or have flexible types.

      2. Step 2: Choose the approach that supports optional price

        Defining price as optional with a matcher allows the provider to omit it without failing the test.

      3. Final Answer:

        Define the contract so price is optional using a matcher that allows missing fields -> Option A

      4. Quick Check:

        Use matchers for optional fields in contracts [OK]
      Hint: Use matchers to allow optional fields in contract tests [OK]
      Common Mistakes:
      • Forcing optional fields to be always present
      • Removing important fields from contract
      • Skipping contract tests and testing only post-deployment
      Recommended

      Ready to prove it?

      Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

      10 questions~5 mineasy hard