Hacker News Reader

Comment by andrewaylett | Hacker News Reader

Why would I write test-cases for something the compiler can catch for me? Yes, I need to write tests for all the correctly-typed cases, but there are a whole class of bugs that I don't need to test for any more because I can't even write the failing case.

View on HN

>there are a whole class of bugs that I don't need to test for any more because I can't even write the failing case.

By adding sanity checking asserts in a dynamically typed language you can achieve more or less the same result.

If you are going to add a bunch of asserts, why not just use types?

I don't particularly see the need to extend this approach to every single variable in my code base. I usually just stick it on boundary code.

You don't write test cases specifically to check types. Your existing cases, if they are robust and thorough, will simulate your runtime and check those for you as a side effect.

My existing test cases, robust and thorough though they are, only test what happens when I feed in a correctly typed object. Because I can't write a test that exercises my code on an incorrectly typed input: the type system prevents that.

you're already writing the test cases to ensure correct behavior with typical input, and predictable exceptional input. putting in one more assert for predictable exceptional input (wrong type) doesn't really add a noticeable amount of overhead to writing the tests you were already writing.

>putting in one more assert for predictable exceptional input (wrong type) doesn't really add a noticeable amount of overhead

Yes. We call that 'typing'.

And it takes less typing (keyboard) than the assert, and you get free documentation inline with the code!

Reply on news.ycombinator.com