3 ms·
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 c
by andrewaylett 9y ago
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.
- enraged_camel 9y agoYou 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.
- andrewaylett 9y agoMy 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.
- metaphorm 9y agoyou'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.
- macspoofing 9y ago>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'.
- discreteevent 9y agoAnd it takes less typing (keyboard) than the assert, and you get free documentation inline with the code!
- crdoconnor 9y ago>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.
- wstrange 9y agoIf you are going to add a bunch of asserts, why not just use types?
- crdoconnor 9y agoI 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.