Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.



>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.



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.


>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.


>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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: