Automatically identify API-breaking changes?

While it is impossible to detect API changes related to semantic differences, it is usually possible to identify whether a public API changed or not, e.g. via function signature or changes to an Enum variants.

Does anyone knows about a tool or binary that, given e.g. two git commit hashes of a repo, automatically detects / reports public API changes between them?

This would be really cool to build changelogs, and also as part of labeling issues e.g. on github.

Though, practically, I'd do the following:

  • test the library only via integration tests in /test directory.
  • watch the changes to the tests to derive info about what's changed in a public API.
4 Likes

Thank you!

wrt to the integration tests, is that the general recommendation, to ensure that only the public API is accessible to the tests (and thus also catch regressions on the API)?

An minor pain point I have atm is the re-compilation of the library when a test is changed. Moving some tests out of the lib files would also aleviate this, right?

I wouldn't call it a general recommendation, but rather my personal preferred testing style. I've found that testing at the boundaries maximizes both the reliability and maintainability of the test suite.

An minor pain point I have atm is the re-compilation of the library when a test is changed. Moving some tests out of the lib files would also aleviate this, right?

Right! Even moving the tests to an out-of-line #[cfg] mod tests; module will help somewhat. Although, if the library itself feels slow to compile, it probably makes sense to work on compile times a bit -- to make an end application pleasant to compile, all libraries it uses should compile very fast, as an app usually uses a lot of libs.

1 Like

Speaking of integration tests and compile times, it's worth mentioning @matklad's advice to combine all integration tests into a single binary, which can greatly reduce link time when building your tests.

3 Likes

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.