The document discusses testing approaches for REST APIs and SAP Hybris integrations: 1. It proposes using Cucumber to create test scenarios in a business-friendly language to send JSON messages to APIs and check HTTP response codes before implementations. 2. It recommends leveraging JSON Path and Cucumber to test JSON expectations in a flexible way that allows for partial fulfillment of expectations. 3. It suggests using expression languages to deal with dynamically generated fields when checking API responses.

1. NS E-commerce integration tests
A test-first approach

2. Summary
• REST API integration tests.
• SAP Hybris integration tests.

3. PROBLEM
• We want to create correct test cases before the API is in place.
• We have a specification.

4. Testing a REST API before it’s implemented
• The mocked responses are set in Mock Server through its API (thus
programmatically).
• The specification is the blueprint for the mocked response.

5. PROBLEM
• How can we create test scenarios that include sending JSON messages to the API in a
business-friendly language?

6. Using Cucumber for checking an HTTP response
code (error 404)

7. Debugging with Fiddler

8. PROBLEM
• How can we create scenarios that check JSON expectations in a readable and
business-friendly way?

9. Checking JSON expectations – rigid approach
• Difficult to test partial
fulfillment of expectations,
which is important while
stories are under active
development.

10. Checking JSON expectations – leveraging JSON
Path and Cucumber

11. Advantages of the flexible approach
• Partial expectations (partial JSON correctness) can be tested.
• The semantics of the JSON message are abstracted from the actual messaging.
• It’s easy to create new test cases, because we don’t need to deal with JSON.

12. Debugging with Fiddler

13. PROBLEM
• Some fields in the response are dynamically generated, how can we create scenarios
that check these?

14. Dealing with dynamic fields: expression language

15. SAP Hybris testing
• In addition to the difficulties that apply to the REST API there is an additional one:
race conditions between tests.
• Test scenarios cannot be launched in parallel.
• Even when the scenarios are run sequentially, manual testing can still interfere and
create race conditions.

16. From test-first to test-driven
• Dependency on seed data.
• Need to test development branches (on CI server or local dev computer), since code
that fulfills acceptance criteria only partially should not be committed to the master
branch.
• Incorporate test-driven on the software development process of the team.