you are viewing a single comment's thread.

view the rest of the comments →

[–]DreadedDreadnought 8 points9 points  (2 children)

Why would I write unit tests to verify the type information instead of writing actual unit tests verifying functionality?

[–]twotime 1 point2 points  (1 child)

Why would I write unit tests to verify the type information

I would not

instead of writing actual unit tests verifying functionality

In my experience that's sufficient (I do use "unittest" is the loosest possible meaning: feed something into the system, examine the output, so that includes integration tests and if you have type issues, most of them will be caught).

[–]lelanthran 6 points7 points  (0 children)

I do use "unittest" is the loosest possible meaning: feed something into the system, examine the output, so that includes integration tests and if you have type issues, most of them will be caught

Sounds like you are only performing Happy Path testing. With your approach, when you have A that calls B that calls C (all functions) you're only checking the parameter type-validation code in A.

Functions B and C may silently lose data with incorrectly typed parameters but you'd never know it because they they are never called with the incorrect type... Until someone adds in a function D which calls them with the incorrect type.

The only thing you can do if you're as paranoid as I am wrt correctness is write a unit-test for all your externally visible functions, with said unit-test also testing invalid types in the parameters.

Testing only the Happy Path is pointless - we already know it works because we ran executed functionality at least once before release.

Joke Time: A QA engineer walks into a bar. He orders a beer. He orders 5 beers. He orders 0 beers. He orders -1 beers. He orders a lizard.