I’m not sure how this really slows you down though. You see the app code is wrong, it breaks a test so you update the test to the new expected result.

The benefit is that the tests highlight what changed in the app. So when you update a library and 1+1 changes, it’s an alarm bell to investigate further because you didn’t expect this to happen.

This is an example the test/hash antipattern. Here, the tests approach a hash of the source code. When some code changes, the hash no longer matches which fails the test. Great, this is letting us know that something as changed. After examining the changes and decide that they are correct, we update the hash and now the all the tests are green again. Our code base has 100% coverage.

This is why tests should be seen as an executable specification rather than simply a series of checks.

Test_OnePlusOneEqualsTwo()

is not as useful as

Test_CanAddTwoNumbersTogether()

Test for behaviour, not implementation.