4 ms·

>You are less likely to rewrite something that is proven to work and has absolutely no tests. Thats emphatically not true if the tests are very low level unit

>You are less likely to rewrite something that is proven to work and has absolutely no tests. Thats emphatically not true if the tests are very low level unit tests that tightly couple to implementation. Theyre a greater impediment to refactoring than 0 tests. Ive worked on a couple of projects like this and seen the same crystallization effect as the OP where people were visibly more afraid of touching unit tested code. These type of tests A) never catch a bug but B) will always fail when you change the code for any reason and C) theyre intimidating to maintain. That means if you refactor the code you usually need to test it just as much manually on top of making the useless tests go green, following whatever dumb pattern they were written with. That increases the workload of changes on that chunk of code by 10-40%. Strictly speaking these types of tests are better off deleted but mid level/junior developers and even many seniors who ought to know better will balk at it due to loss aversion. Ive noticed that this is also the type of bullshit test ChatGPT will write when cajoled so I anticipate seeing much more of this in the years to come.

octacat 3y ago
If tests are very low quality it is the same as no tests. (so recursion here). If tests are low quality, they somehow managed to pass the code review. So, I would have more wider questions to the project, knowing this. Adjusting tests require 10% during refactor? Yes, it is fine (getting some uncovered rare regression bug in prod is not fine). Manual testing after refactor? No, it is not fine (and manual testing should be automated before the refactor. With end-to-end/integration testing. In the ideal world). Sadly, it all depends on managers, many projects are just "Just doo it", so nobody cares about keeping the tests sane. Oh yea, flaky, weird, non-documented tests would increase load by 40% to the new devs and that is true evil.
- MoreQARespect 3y ago
  >If tests are low quality, they somehow managed to pass the code review. So, I would have more wider questions to the project, knowing this. The answer to this is almost always a lack of skill or that the team was focused on delivery and were willing to neglect test quality in pursuit of that goal. Either way it's a common enough situation that can't just be handwaved away. Even if you've fired the team members responsible for that code the code doesnt just go away.

octacat 3y ago

If tests are very low quality it is the same as no tests. (so recursion here). If tests are low quality, they somehow managed to pass the code review. So, I would have more wider questions to the project, knowing this. Adjusting tests require 10% during refactor? Yes, it is fine (getting some uncovered rare regression bug in prod is not fine). Manual testing after refactor? No, it is not fine (and manual testing should be automated before the refactor. With end-to-end/integration testing. In the ideal world). Sadly, it all depends on managers, many projects are just "Just doo it", so nobody cares about keeping the tests sane. Oh yea, flaky, weird, non-documented tests would increase load by 40% to the new devs and that is true evil.

MoreQARespect 3y ago
>If tests are low quality, they somehow managed to pass the code review. So, I would have more wider questions to the project, knowing this. The answer to this is almost always a lack of skill or that the team was focused on delivery and were willing to neglect test quality in pursuit of that goal. Either way it's a common enough situation that can't just be handwaved away. Even if you've fired the team members responsible for that code the code doesnt just go away.