Skip to content

Instantly share code, notes, and snippets.

@eliasnogueira

eliasnogueira/presentation1.md

Last active September 11, 2022 17:17
Show Gist options
  • Star 1 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save eliasnogueira/2d42f5180b84d34e6925e494522fedac to your computer and use it in GitHub Desktop.
Save eliasnogueira/2d42f5180b84d34e6925e494522fedac to your computer and use it in GitHub Desktop.
Download ZIP
Expanding the API test coverage
Raw
presentation1.md

Expanding the API test coverage

Description of the session

Are the unit tests of your team uncovering bugs before the user? Are you certain that your unit or integration tests will guarantee good coverage? Can you reproduce some end-to-end tests in your API? Given the last wave of adopted architectural changes on many backend systems, the best coverage in any aspect is necessary. Even though developers create integration or end-to-end tests in a REST endpoint there’re other testing techniques and levels to be applied to smash the bugs during the development process.

As Software Engineers, we’re concerned about to create the maximum test coverage for our API’s through unit and integration tests (shift-left test) using mocks to support a better strategy and removing dependencies. However, to have a great breadth of test coverage we need to think about more types of testing and, mainly, how can we execute them applied to a pipeline to deliver our APIs through a Continuous Delivery or Continuous Deployment strategy following their test pyramid to have faster feedback about our application health.

Takeaways

  • learn how to automated an API applying health-check, contract, functional and acceptance tests
  • learn how to create a pipeline division of API tests with a good coverage
  • learn how to apply some design patterns focusing on API testing
@Heather-R
Copy link

I feel like there is something missing between these sentences "Can you reproduce some end-to-end tests in your API? Given the last wave of adopted architectural changes on many backend systems, the best coverage in any aspect is necessary." I don't see how they link together. Perhaps an additional sentence would suffice to link them?

"However, to have a great breadth of test coverage we need to think about more types of testing and, mainly, how can we execute them applied to a pipeline to deliver our APIs through a Continuous Delivery or Continuous Deployment strategy following their test pyramid to have faster feedback about our application health." This is a really long sentence to read with a lot of information in it, I'd suggest breaking it up into two or more sentences if you can to make it easier for reviewers to digest.

In the takeaways:
"learn how to automated an API applying health-check, contract, functional and acceptance tests" are they going to learn how to automate an API or are they going to learn how to build health checks into the API? These are subtly different learning goals.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment