4 ms·

I don't get it. Beck was quite explicit when coining the term "unit tests" that the unit refers to the set of functionality found at the integration point – whi

I don't get it. Beck was quite explicit when coining the term "unit tests" that the unit refers to the set of functionality found at the integration point – which seems to be what you refer to as "integration tests", and what everyone else these days call "tests". It's all the same. If changes to "local functions" calls for tests to be rewritten, that means you've exposed "local functionality", even if by accident, to the outside user. Which means it is not actually local functionality, but something you have exported and are committed to maintaining. Rewriting the tests is not the correct course of action. You need to fix the code that you just broke as the functional contract was violated. With any luck that hard lesson will teach you to be more careful next time.

zelphirkalt 2y ago
Unless of course, someone before you has written lots of tests for all the functions separately, regardless of whether they represent functionality at the integration point and there is a culture of not wanting to delete tests, because of coverage reasons. Then what you have are suddenly broken tests, even if you change only procedures at a lower level.
- randomdata 2y ago
  Deleting the tests will not impact coverage as the tests at the integration points will necessarily already cover any local functions. That is unless said local functions are unused, but in that case you would remove the unused local functions anyway, still not impacting coverage. But you are right that deleting the tests isn't an option as it will break the contract that was entered into with the users of the code. Of course, you can't modify the tests for the same reason, so...