When I've got code that outputs what I want, I'm often tempted to skip writing tests. Invariably, after forcing myself to write some, I'll discover an edge case that doesn't perform as expected and be reminded anew that this is why I'm writing them.
@pyrmont For me, it helps to write a happy path test case first. Make it pass, then write a few things that should obviously fail with bad input. Helps make sure I always have a test for something.
@wa9ace I think I'd like to get there. My issue at the moment is that I rarely understand well enough the 'shape' (for want of a better word) the code and so writing tests feels like putting the cart before the horse.
@pyrmont But you said "when I've got code that outputs what I want"
Deep down there is one predicate that you use to decide if the piece of code is "giving what you want". All it takes is putting that predicate into an assertion first.
But sometimes I open the fridge first before knowing what I want as well 😃
@skeang My initial reaction is to say that, when it comes to an integration test, that's true. But it's unit tests where I tend to catch bugs and these I find very difficult to write in advance.
A Mastodon instance for Rubyists & friends