Great plug haha. Bought and almost 50% through. Loving it so far.

However I am wondering about statements like “The goal of TDD is to create a test suite that you would trust with your life.”

Is that really possible? I can only think about so many edge cases. Never all of them. If I refactor a module and see all green I might be confident in that system, but what happens if my refactoring causes an edge case to error, that used to just slip through? Won’t it re-introduce the fear of touching the old code?

Reply to this note

Please Login to reply.

Discussion

fuzz tests fill most of the gaps and find you problems

good real world data sets can stress test your code too, nostr:npub12262qa4uhw7u8gdwlgmntqtv7aye8vdcmvszkqwgs0zchel6mz7s6cgrkj provided me with a gigadump of 180Gb of event data and it uncovered several bugs in my json parsing code (and revealed that maybe over 1% of all events are malformed so far)

From: Egge<-DerekRoss at 05/26 10:57

> Great plug haha. Bought and almost 50% through. Loving it so far.

>

> However I am wondering about statements like “The goal of TDD is to create a test suite that you would trust with your life.”

>

> Is that really possible?

No. It's an asymptotic goal. You'll never get all the way there; but you can get to the point where you trust the test suite enough to deploy the system without fear.

>...what happens if my refactoring causes an edge case to error, that used to just slip through? Won’t it re-introduce the fear of touching the old code?

A refactoring is a small change to the code that improves structure without changing behavior. So, theoretically, a refactoring will not create such an "edge case". Realistically, however, such things _do_ occur. You have to be careful.

Still, it is possible to create a test suite that robustly resists most such "edge cases" and that you trust well enough to deploy without fear.

CC: #[4]