Upgrade to Pro — share decks privately, control downloads, hide ads and more …

How to create modular microservices test project

Elias Nogueira
September 21, 2021

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.

Elias Nogueira

September 21, 2021
Tweet

More Decks by Elias Nogueira

Other Decks in Technology

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