3 ms·
The concept of refactor does not apply in context of publicly exposed interfaces—i.e., you logically never “refactor” a public API, you release a new version of
by strogonoff 3y ago
The concept of refactor does not apply in context of publicly exposed interfaces—i.e., you logically never “refactor” a public API, you release a new version of it. As such, it would have different inputs and outputs and therefore its own separate tests.
This becomes more difficult to reason about when what you build is not just a library but something more like a web service or a GUI/CLI app. For a library, a unit test may be able to cover public API and be an end-to-end test in effect, whereas for a more complex product intended to exist over time in production unit tests do in fact provide less of a guarantee, and versioning public API becomes difficult (unless you immediately drop support for any non-current API version).
- SideburnsOfDoom 3y agoIt is useful to be able to refactor the code behind that interface, or 1 or more levels down the call stack, while testing via that public interface. Contract changes is one reason for such a code change, but there are many others - including bug fixes, error handling, handling input cases that were not well supported before, performance or readability improvement, changing to use a new version of an internal library with a new contract, and pure refactoring to e.g. extract common code, with no other logical change. it is useful to do such incremental changes supported by tests on a "publicly exposed interface" that does not change frequently, instead of tests coupled to classes that are not not part of a "publicly exposed interface".
- deleted 3y ago[deleted]
- strogonoff 3y agoAbsolutely. If there is no logical change to a public interface, then your e2e tests (irrespective of whether they are unit tests, where units are strictly public members or classes or modules, or some other kind of tests) should not change either.