4 ms·

> because of all the tests you will have to rewrite If you have to rewrite tests that means you've changed the user experience in ways that are not backwards c

> because of all the tests you will have to rewrite If you have to rewrite tests that means you've changed the user experience in ways that are not backwards compatible. Which is sometimes valid, but not exactly what is being talked about here. The discussion here is more about changing the code in ways that makes the code better, but still delivers the same user experience – possibly with new features added, but not where anything is taken away.

Jensson 2y ago
> If you have to rewrite tests that means you've changed the user experience in ways that are not backwards compatible. That is only true for integration tests. You can rewrite a set of local functions without changing user behavior, and then you need to change tests, such refactors becomes a pain when you have too many unit tests but are really easy when you have many integration tests.
- randomdata 2y ago
  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...

Jensson 2y ago

> If you have to rewrite tests that means you've changed the user experience in ways that are not backwards compatible. That is only true for integration tests. You can rewrite a set of local functions without changing user behavior, and then you need to change tests, such refactors becomes a pain when you have too many unit tests but are really easy when you have many integration tests.

randomdata 2y ago
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...