Type-checking and spec-testing with TypeCheck
A guide on how to use TypeCheck and automated spectesting to make it impossible to use your functions incorrectly and reduce the amount of bugs you ship to production.
2 Likes
Looks similar to what I was making at one point except for checking the specs at compile-time, have you thought about performing checks at compile-time, at least the checks that are performable? I’d recommend caching those when possible, as otherwise creating a dependency graph is annoying, or perhaps just running them as another pass?
1 Like
There are no parameter-checks happening at compile-time as being passed a constant at compile-time is (a) relatively hard to detect (or put differently, there are many variations of passing a constant which don’t let the macro see the value as a constant) and (b) a bit of an edge-case which would make the code significantly more complicated.
Of course, as the code is inlined into the actual functions, the Elixir and Erlang compilers are able to significantly optimize them and remove redundant checks.
What TypeCheck does do itself is that TypeCheck’s checks are used to add type-checks on its own functions, including the ones used to actually build the types. This means that you will get compile-time errors if you try to use the library wrong. From the perspective of TypeCheck, these compile-time errors are of course at runtime, as the TypeCheck modules themselves have already been compiled 
.
(Side note: It was a fun exercise in metaprogramming to make this work.)
2 Likes
make it impossible to use your functions incorrectly
is a rather bold claim. I betcha I could still screw up. 
More importantly though:
types can be composed, re-used and turned into property-testing generators
Now this sounds interesting. I’ve been meaning to check out property testing, not just to use but also to turn into a conference talk, possibly in combo with mutation testing and any other “weird tricks” I can find in the dev-testing domain.
2 Likes