3 ms·

> Unit tests will actually make bad code even worse because it will be even more difficult to change the underlying logic (because the tests lock all the poor i

> Unit tests will actually make bad code even worse because it will be even more difficult to change the underlying logic (because the tests lock all the poor implementation details into place). This statement is patently false, unless for some reason a project includes unit tests themselves as the production code, which would be highly unusual. At most, unit tests must be refactored along with the code, but that's the standard operating procedure.

rement 7y ago
I actually just finished a ticket related to this. It took me significantly longer than necessary because I also had to go through all the poorly written tests.
cryptica 7y ago
But while you're building a new system/subsystem, it doesn't make sense to write unit tests for units of code which have a high likelihood of being deleted 1 month from now due to evolving project requirements. It's like if you were building a smartphone; it wouldn't make sense to screw all the internal components into place one by one unless you were sure that all the components would end up fitting perfectly together inside the case. While building the prototype, you may decide to move some components around, downsize some components, trim some wires and remove some low-priority components to make room for others. In this case, unit tests are like screws.
- gnator 7y ago
  The problem is prototypes end up being production code in the real world. Writing tests is about managing risk. You should write some basal level of unit test as you go to validate your logic as you go. That basal level is determined by the team or individual tolerance of risk
  - v-erne 7y ago
    Who said anything about production ? Haven't You seen requirements changing even before first prototype is ready? I had a meeting literally today where client's CFO and head accountant throw out my team's week of work because they forgot about key requirements (and this have happened third time this year)
jen20 7y ago
This seems to assume that the tests will be higher quality than the problematic code in the first place. It’s actually commonplace to see tests coupled to internal implementation details of production code, which makes refactoring very hard. The idea of TDD (mostly lost to hype and consultants) is that you change _EITHER_ the tests or the code in each operation. This allows you to use one as a control against the other. If you change both, you prove that different tests pass against different code, which is substantially less useful. Unfortunately if tests are coupled to internal state, getting code to even compile without modifying both sides of the production/test boundary is difficult after a refactor.
- geezerjay 7y ago
  > This seems to assume that the tests will be higher quality than the problematic code in the first place. If the problem lies with probematic code then tests are not the problem. At most they're just yet another way that problematic code affects the problem. Let's put it this way: would the problems go away if the tests were ripped out?

rement 7y ago

I actually just finished a ticket related to this. It took me significantly longer than necessary because I also had to go through all the poorly written tests.

cryptica 7y ago

But while you're building a new system/subsystem, it doesn't make sense to write unit tests for units of code which have a high likelihood of being deleted 1 month from now due to evolving project requirements. It's like if you were building a smartphone; it wouldn't make sense to screw all the internal components into place one by one unless you were sure that all the components would end up fitting perfectly together inside the case. While building the prototype, you may decide to move some components around, downsize some components, trim some wires and remove some low-priority components to make room for others. In this case, unit tests are like screws.

gnator 7y ago
The problem is prototypes end up being production code in the real world. Writing tests is about managing risk. You should write some basal level of unit test as you go to validate your logic as you go. That basal level is determined by the team or individual tolerance of risk
- v-erne 7y ago
  Who said anything about production ? Haven't You seen requirements changing even before first prototype is ready? I had a meeting literally today where client's CFO and head accountant throw out my team's week of work because they forgot about key requirements (and this have happened third time this year)

jen20 7y ago

This seems to assume that the tests will be higher quality than the problematic code in the first place. It’s actually commonplace to see tests coupled to internal implementation details of production code, which makes refactoring very hard. The idea of TDD (mostly lost to hype and consultants) is that you change _EITHER_ the tests or the code in each operation. This allows you to use one as a control against the other. If you change both, you prove that different tests pass against different code, which is substantially less useful. Unfortunately if tests are coupled to internal state, getting code to even compile without modifying both sides of the production/test boundary is difficult after a refactor.

geezerjay 7y ago
> This seems to assume that the tests will be higher quality than the problematic code in the first place. If the problem lies with probematic code then tests are not the problem. At most they're just yet another way that problematic code affects the problem. Let's put it this way: would the problems go away if the tests were ripped out?