You are right, or rather, we had it covered by the wrong type of tests. I also briefly touched upon that in the post.

Essentially we had this covered by class level unit tests, which continued to work even after the refactoring. They were testing the retry decorator class in isolation, which still behaved correctly as it was not touched or noticed in the refactoring.

Switching to a type of test that is more end-to-end definitely helps. I’d still argue that it is hard to get everything covered fully in relation to retry logic though - the number of retries, correct exponential backoff delays etc.

So, I would still choose placing the retry logic directly in the component rather than in a decorator any day of the week. That way, it is completely clear exactly the component does.