How to create modular microservices test project

In this presentation, you will learn how to break down the test project into smaller pieces. This is one of the proposed methods when you have many microservices handled by different teams.

With smaller and decomposed projects you can share some commons, like clients, shared libraries, and shared code in projects to avoid duplication and enable a centralized point for changes.

Transcript

1. How to create modular
   microservice test projects
   Elias Nogueira
   

   View Slide

2. Elias Nogueira
   I help professional software engineers
   (backend, frontend, qa) to develop their quality
   mindset and deliver bug-free software so they
   become top-level engineers and get hired for
   the best positions in the market.
   🏢
   Backbase
   👨💻‍‍
   Principal Software Engineer
   📍
   Utrecht, the Netherlands
   🌐
   eliasnogueira.com
   🐦
   @eliasnogueira
   bit.ly/eliasnogueira
   

   View Slide

3. What problem do we
   want to solve?
   

   View Slide

4. Implicitly we want …
   ● Increase confidence in delivery
   ● Cover key business scenarios
   ● The certainty that the test will find a possible failure
   after some modification
   

   View Slide

5. API anatomy (testing perspective)
   

   View Slide

6. Individual APIs
   API
   API
   API
   API
   API
   API
   API
   API
   Each microservice is a small feature that runs in isolation.
   

   View Slide

7. Individual APIs
   Unit Tests
   done!
   API
   API
   API
   API
   API
   API
   API
   API
   Each API must have its unit tests and integration.
   Integration
   Tests* done!
   * API Tests running in an
   integration layer with or
   without mocks
   

   View Slide

8. API
   API
   API
   API
   API
   API
   API
   API
   The problem
   Integration tests won’t cover real scenarios of dependent APIs
   because of the mocks.
   depends
   consum
   es
   

   View Slide

9. Possible solution
   

   View Slide

10. API
    API
    API
    API
    API
    API
    API
    API
    Possible solution
    Create functional tests and e2e to cover possible gaps and
    decrease the test on the UI.
    Functional
    Tests
    &
    E2E
    

    View Slide

11. API
    API
    API
    API
    API
    API
    API
    API
    Possible solution
    What
    Add tests to any kind of dependencies, as well for the user journey
    depends
    consum
    es
    

    View Slide

12. Analogy: buying a flight ticket
    

    View Slide

13. Buying a flight ticket
    We must make sure each API is self-tested
    unit -> integration -> functional
    Search Flight selection Payment Confirmation
    API API API API
    

    View Slide

14. Buying a flight ticket
    We must make sure each API is self-tested
    unit -> integration -> functional
    Search Flight selection Payment Confirmation
    Valid dates
    Invalid return date
    No flights found
    API API API API
    

    View Slide

15. Buying a flight ticket
    We must make sure each API is self-tested
    e2e: buy a round-trip flight
    Search Flight selection Payment Confirmation
    Select valid
    dates
    API API API API
    Select a flight
    with seats
    available Make a
    payment with
    valid data Successful
    notification
    E2E Scenario
    

    View Slide

16. How can test projects be
    created?
    

    View Slide

17. Model 1
    A test project for all microservices
    BACKEND
    TEST
    TEST
    PROJECT
    

    View Slide

18. Model 1
    Pros
    ● Centralization of code in a single project
    ● Speed and agility in creating tests and solving problems
    Cons
    ● Constant changes by several people can have side effects on
    results
    

    View Slide

19. Model 2
    A test project for each microservice where interactions
    with the endpoint (s) will be in the test project.
    BACKEND
    TEST TEST TEST
    TEST
    PROJECT
    

    View Slide

20. Model 2
    Pros
    ● Organized decentralization of test projects towards an API
    ● Isolation between APIs
    Cons
    ● Possible code duplication
    

    View Slide

21. Model 3
    A test project for each microservice divided into client and
    test projects
    BACKEND
    TEST
    PROJECT
    TEST TEST TEST
    CLIENT CLIENT CLIENT
    

    View Slide

22. Model 3
    Client project
    We will put here all the necessary logic to make the
    requests as:
    ○ Exception return
    ○ Transport Objects
    ○ Request call
    ○ Customizations for validations
    ○ Pointing settings (URI, base path, port)
    

    View Slide

23. Model 3
    Test Project
    We will put here all the methods of using the API we
    created in the client project, creating the testing logic
    and validating the results.
    In summary, all tests are created here!
    

    View Slide

24. Model 3
    Pros
    ● Greater version management (new features, breaking changes)
    ● Easy use by other teams
    ○ they just need to consume the customer and create their tests
    Cons
    ● Time increase compared to previous models
    

    View Slide

25. Implementation exemple
    

    View Slide

26. Implementation example
    Project separation
    BACKEND
    TEST
    PROJECT
    TEST TEST TEST
    CLIENT CLIENT CLIENT
    COMMONS
    PARENT
    

    View Slide

27. Project separation
    CLIENT
    TEST
    COMMONS
    PARENT
    Project containing all calls to the microservice, whether the calls
    were successful or simulating exceptions.
    Project containing tests for the microservice, testing its
    functionality and dependencies with other microservices.
    Code and libraries common to clients such as URL definitions,
    authentication, and any other shared code.
    Code and libraries common to tests such as data mass, support
    functions, or any code common to tests.
    

    View Slide

28. Microservice examples
    Possible graphical interface: Constraint check by CPF
    We should inform a CPF
    * Its a Brazilian social
    security number
    If a restriction is found,
    show a message
    

    View Slide

29. Microservice examples
    Possible graphical interface:
    Loan Simulation
    Fill in loan
    information
    

    View Slide

30. Microservice examples
    We will put here all the necessary logic to make
    the requests as:
    RESTRICTIONS
    GET /api/v1/restricrions/{cpf}
    GET /api/v2/restricrions/{cpf}
    Constraint Query
    API
    SIMULATIONS
    GET /api/v1/simulations/
    GET /api/v1/simulations/{cpf}
    POST /api/v1/simulations/
    PUT /api/v1/simulations/{cpf}
    DELETE /api/v1/simulations/{cpf}
    Credit Simulation
    API
    

    View Slide

31. Client’s implementation
    Methods will be created to simulate all possible calls from
    each HTTP method
    CLIENT
    RESTRICTIONS
    GET /api/v1/restricrions/{cpf}
    Constaint Query
    API Client
    Method - find CPF
    Method - find CPF and return an exception
    

    View Slide

32. CLIENT
    SIMULATIONS
    GET /api/v1/simulations/
    GET /api/v1/simulations/{cpf}
    POST /api/v1/simulations/
    Credit Simulation
    Client API
    Method – find all simulations
    Method – find a simulation by a given CPF
    Method – find a simulation by a given CPF and return not found
    Method – submit a simulation
    Method – submit a simulation and return unprocessable entity
    Method – submit a simulation and return conflict
    Methods will be created to simulate all possible calls from
    each HTTP method
    Client’s implementation
    

    View Slide

33. CLIENT
    SIMULATIONS
    POST /api/v1/simulations/
    Credit Simulation
    Client API
    Method – submit a simulation
    A test method will be created for one or more use of the
    methods on the client
    Test implementation
    TEST
    SIMULATIONS
    should create a successful simulation - Test
    Credit Simulation
    Test Project
    

    View Slide

34. CLIENT
    SIMULATIONS
    POST /api/v1/simulations/
    Method – submit a simulation and return unprocessable entity
    A test method will be created for one or more use of the
    methods on the client
    TEST
    SIMULATIONS
    should show an error regarding an attribute not sent in the request
    - Test
    - Test
    Credit Simulation
    Client API
    Credit Simulation
    Test Project
    Test implementation
    Method – submit a simulation
    should create a successful simulation
    

    View Slide

35. CLIENT
    SIMULATIONS
    POST /api/v1/simulations/
    Method – submit a simulation and return conflict
    TEST
    SIMULATIONS
    should show conflict when CPF already exists - Test
    Credit Simulation
    Client API
    Credit Simulation
    Test Project
    A test method will be created for one or more use of the
    methods on the client
    Test implementation
    Method – submit a simulation and return unprocessable entity
    should show an error regarding an attribute not sent in the request
    - Test
    - Test
    Method – submit a simulation
    should create a successful simulation
    

    View Slide

36. How to use client <-> test?
    

    View Slide

37. How to use client <-> test?
    Through the client version
    ● We must add the client dependency in the test
    
    com.eliasnogueira
    simulations-client
    1.2.5
    
    "devDependencies": {
    "@eliasnogueira/simulations-client": ”1.2.5",
    }
    Java + Maven example
    Typescript + Node example
    

    View Slide

38. How to use client <-> test?
    Pros: association of the client
    with the microservice version
    Just as the microservice evolves the
    client and the test evolve. Adding a
    changelog with the association of the
    client version with the microservice
    version can help fix bugs.
    Also tags helps if you would like to track
    the evolution.
    

    View Slide

39. Recap
    

    View Slide

40. Recap
    ● We created a robust model for
    ○ test a microservice in isolation (functional test)
    ○ test a microservice and its dependencies (e2e)
    ● We modularize the creation of projects
    ○ client: the entire API call for a microservice
    ○ test: test project using the microservice client
    ○ commons: client codes and libraries
    ○ parent: test code and libraries
    

    View Slide

41. Thank you!
    SCAN ME
    You can follow me on Twitter
    @eliasnogueira and find the
    practical examples of this
    presentation. Be sure to
    simulate the examples in the
    code!
    

    View Slide

42. Projects
    • https://github.com/eliasnogueira/test-parent
    • https://github.com/eliasnogueira/test-commons
    • https://github.com/eliasnogueira/restrictions-client
    • https://github.com/eliasnogueira/restrictions-test
    • https://github.com/eliasnogueira/simulations-client
    • https://github.com/eliasnogueira/simulations-test
    

    View Slide

43. Important note
    To be able to run the Project locally, after you clone it, you
    must configure the GitHub Packages in your pom.xml file.
    You can find the example here:
    https://docs.github.com/en/packages/working-with-a-github-
    packages-registry/working-with-the-apache-maven-registry
    Replace the OWNER by eliasnogueira
    

    View Slide