-3

I have an infrastructure package that multiple projects depend upon. This package is supposed to be a stable API shared by those projects.

I want to know if a change made in the package has broken older functionality and changed api.

In more detail, I want to automate the test on the CI that makes sure that if a user has broken an api that another app has relied on, he will have to change a major version of the package to let the users know that functionality is inherently different now.

What are the ways to test that an API has changed?

3
  • 2
    Is this an HTTP API? Or an API of a software library that is run in the process of those other projects? Or something else.
    – bdsl
    Feb 8 at 11:27
  • It's a javascript package but that doesn't matter. I'm interested in high level ideas and solutions.
    – Ziv
    Feb 8 at 16:09
  • Do you have unit and/or integration tests?
    – Polygnome
    Feb 9 at 9:58
2

You want consumer-driven contract (CDC) testing. Basically, your customers demonstrate how they expect to use the API in a way so that you can re-run their tests before you deploy a change to your code.

(Beware: currently it is hard to search for "CDC tests" because you drown in covid-related results about genetic testing.)

0

I think the proper approach for making sure the APIs are not changed and the other 3rd parties won't be impacted after this update is writing Integration Test in your CI/CD Process.

What is integration testing - [Read More]

0

An idea that we had was to take the tests from the previous version and run them against the current version to make sure that code that depended on the old tests would not break as the tests represent the behavior that the client code would depend upon.

This means that people can't change existing behavior by modifying the tests (which would be a breaking change) or delete code that was already tested.

1
  • 1
    This will work as long as the tests conform to the API you've produced. If consumers of your API use something that's not covered by your tests, then you are likely to miss it. For example, let's say that you expose a sum functionality that adds together two values. However, for whatever reason an update makes it work only with positive numbers. If you never test for it and a consumer is already using it to add together negative numbers, then you've broken the API. This also depends on whether you've previously documented the only positive behaviour.
    – VLAZ
    Feb 9 at 10:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.