4 ms·

> If you are unit testing you should not have to worry about tweaking a function and it breaking everywhere else. "should" is a word loaded with authority. Wh

> If you are unit testing you should not have to worry about tweaking a function and it breaking everywhere else. "should" is a word loaded with authority. Why? If you believe a unit tests is for turning an impure function into a pure function (so you can just test what it's doing and no other effects), then in many cases tweaking will break existing unit tests. If the function exists, it's assumed it's used by more than the tests for it. Changing the signature or even the internal dependencies necessarily breaks the known contracts with other units.

chii 4y ago
> breaks the known contracts with other units. which either forces you to fix those contracts - implying you have to go understand those contracts too. Or, you un-abstractify the function by keeping the original, and add a copy with the modifications you needed for the new feature/fix. This keeps the original contracts intact, but you add "bloat" to code - a form of tech-debt.
- Supermancho 4y ago
  Indeed on both counts. This is a demonstration of why a code change may seem simple in theory, but when you actually do it, you can see all the side effects that you didn't consider when estimating. This is one of the many ways that estimation without looking at existing code, can be completely off...not to say it will be right-on when estimating and looking at code. I have worked a company with 8 hour planning, where every single change is by committee while looking at existing code. Mercifully, this methodology didn't last more than a few months.
edgyquant 4y ago
No it doesn’t and I’d hate to have you working on my team with this mindset.
- Supermancho 4y ago
  > even the internal dependencies necessarily breaks the known contracts with other units The implication is that there are unit tests for those dependencies as well. Changing the signature used for them, breaks the same contracts as a wrapping function signature change. Ofc, you may already have tests to cover alternate signatures (overloading, et al) but conceptually it's the same pitfall.

chii 4y ago

> breaks the known contracts with other units. which either forces you to fix those contracts - implying you have to go understand those contracts too. Or, you un-abstractify the function by keeping the original, and add a copy with the modifications you needed for the new feature/fix. This keeps the original contracts intact, but you add "bloat" to code - a form of tech-debt.

Supermancho 4y ago
Indeed on both counts. This is a demonstration of why a code change may seem simple in theory, but when you actually do it, you can see all the side effects that you didn't consider when estimating. This is one of the many ways that estimation without looking at existing code, can be completely off...not to say it will be right-on when estimating and looking at code. I have worked a company with 8 hour planning, where every single change is by committee while looking at existing code. Mercifully, this methodology didn't last more than a few months.

edgyquant 4y ago

No it doesn’t and I’d hate to have you working on my team with this mindset.

Supermancho 4y ago
> even the internal dependencies necessarily breaks the known contracts with other units The implication is that there are unit tests for those dependencies as well. Changing the signature used for them, breaks the same contracts as a wrapping function signature change. Ofc, you may already have tests to cover alternate signatures (overloading, et al) but conceptually it's the same pitfall.