4 ms·

The fact that you think "change detection" tests offer zero value speaks volumes. Those may well be the most important use of unit tests. Getting the function c

by tensor 2y ago

The fact that you think "change detection" tests offer zero value speaks volumes. Those may well be the most important use of unit tests. Getting the function correct in the first place isn't that hard for a senior developer, which is often why it's tempting to skip unit tests. But then you go refactor something and oops you broke it without realizing it, some boring obvious edge case, or the like. These tests are also very time consuming to write, with lots of boilerplate that AI is very good at writing.

mattmanser 2y ago
I think you've misunderstood what he meant by change detection (not GP, could be wrong). Hard to describe, easy to spot. Some people write tests that are tightly coupled to their particular implementation. They might have tons of setup code in each test. So refactoring means each test needs extensive rewrites. Or there will be loads of asserts that have little to do with the actual thing being tested. These tests usually have negative value as your only real option as another developer is to simply delete them all and start again. That's what I would interpret the GP as meaning when they use the phrase "change detection" tests.
- DeathArrow 2y ago
  >Some people write tests that are tightly coupled to their particular implementation. That is not due to people choice but due to what actual code being tested does. I think integration tests and end to end tests are much better.
chairhairair 2y ago
https://testing.googleblog.com/2015/01/testing-on-toilet-change-detector-tests.html https://testing.googleblog.com/2015/01/testing-on-toilet-cha... "speaks volumes" lol
DeathArrow 2y ago
>The fact that you think "change detection" tests offer zero value speaks volumes. But code should change. What shouldn't change, if business rules don't change, is APIs and contracts. And for that we have integration tests and end to end tests.
DeathArrow 2y ago
>But then you go refactor something and oops you broke it without realizing it, some boring obvious edge case, or the like I will start to care when integration tests are failing, because that is an actual bug. Then I will fix the bug and move over.

by tensor 2y ago

mattmanser 2y ago

I think you've misunderstood what he meant by change detection (not GP, could be wrong). Hard to describe, easy to spot. Some people write tests that are tightly coupled to their particular implementation. They might have tons of setup code in each test. So refactoring means each test needs extensive rewrites. Or there will be loads of asserts that have little to do with the actual thing being tested. These tests usually have negative value as your only real option as another developer is to simply delete them all and start again. That's what I would interpret the GP as meaning when they use the phrase "change detection" tests.

DeathArrow 2y ago
>Some people write tests that are tightly coupled to their particular implementation. That is not due to people choice but due to what actual code being tested does. I think integration tests and end to end tests are much better.

chairhairair 2y ago

https://testing.googleblog.com/2015/01/testing-on-toilet-change-detector-tests.html https://testing.googleblog.com/2015/01/testing-on-toilet-cha... "speaks volumes" lol

DeathArrow 2y ago

>The fact that you think "change detection" tests offer zero value speaks volumes. But code should change. What shouldn't change, if business rules don't change, is APIs and contracts. And for that we have integration tests and end to end tests.

DeathArrow 2y ago

>But then you go refactor something and oops you broke it without realizing it, some boring obvious edge case, or the like I will start to care when integration tests are failing, because that is an actual bug. Then I will fix the bug and move over.