Hacker News new | ask | show | jobs
by shhsshs 2409 days ago
I see a test as a declaration of intended outcome. By writing a test to expect an intentional failure (say you have a bug in a divide: “int -> int -> Maybe int” function that causes it to return 0 when you divide by 0 instead of “None”) you are declaring that is actually intentional behavior. So I would never write a test like this - I think I would prefer committing the fix and the new test at once. I don’t see the value in reviewing them separately, because they are related and dependent changes.

Obviously if you view tests differently (eg. as a declaration of current behavior rather than intended behavior) then my argument dies.

1 comments

Keep in mind the test is written with the correct behaviour and annotated to be failing — in a hypothetical language and framework your test would be

@failing testDivZero() { assertEquals(None, div(1, 0)) }

This expresses both the intent and the reality