[nrinaudo]

Or, you know, write property-based tests instead, so you only need to worry about the logic and not the test values.

I've always found that if you let the author of a piece of code decide on what value that code should be tested with, he'll test for the edge cases that he's thought of (and dealt with), not the ones that actually crash production.

[kazagistar]

I think both are important. Use property-based tests to fuzz for mistakes you might have made. Use hardcoded value tests to ensure that common future breakages of edge cases are caught, and to validate that your property-based tests are even doing anything.

Usually, property-based tests are more complex, which means that the chance of an logic error in the test increases, and having something easy to verify hardcoded brings peace of mind.

[couchand]

On the other hand, if you ask the author to think of the edge cases first, they're more likely to list them and then write code that handles them. Still no guarantee, but better than writing tests for code you just "finished".

[nrinaudo]

But still, you end up with tests for what the author feels his code should handle, not necessarily what the real world is actually like.

Don't get me wrong, that's still valuable - if only for the non-regression aspect - but I feel property-based testing is a superior approach.

Write your code ("this is a function that sorts lists of ints"), write a property ("when given a list of ints, after sorting it, elements should be sorted and the list should have the same size"), let the framework generate test cases for you. Whenever something breaks ("lists of one element come back empty"), extract the test case and put it in a unit test to make sure the same issue doesn't crop up again in the future.