> simple unit tests aren't the important ones<p>And yet, they prevented me from committing dumb mistakes to the main branch so many times.<p>> types are just simple unit tests written for you<p>Even better if I don't have to write them. Is this really a counter argument?<p>> dynamic languages only need unit tests because they don't have type systems<p>But every language has a type system! How would they differentiate an integer from a string if they don't?<p>Even assembly has a type system (byte vs word vs double-word).<p>Am I just nitpicking or is that argument fundamentally flawed and ignorant?<p>> What's going on here? These can't both be right.<p>They can both be wrong though, and they seem to be IMHO.<p>This does not incite me to watch the 20min video. This seems too click-baity.
This sounds a bit like a 'no true Scotsman' (i.e. the bar would be moved with any example of a bad unit test that needs types), but I would need think more on it.<p>In my opinion, unit tests need to cover multiple levels, at least two, the units, and also the business logic, and proper types would cover the gaps in between. If anything I would invert the title of this, and say a strong enough type system makes unit tests unnecessary, but I don't think that's anything new and you can see it at work in pure FP languages like Haskell.
Some people claim that unit tests make type systems unnecessary: "types are just simple unit tests written for you, and simple unit tests aren't the important ones". Other people claim that type systems make unit tests unnecessary: "dynamic languages only need unit tests because they don't have type systems." What's going on here? These can't both be right. We'll use this example and a couple others to explore the unknown beliefs that structure our understanding of the world.
I think "types" are just compile-time unit-tests.<p>But unlike conventional "unit-tests" they also apply inside the code, not just on its externally observable call-boundary.<p>So perhaps more appropriately then types are "reusable assertions".