I just realized I completely misread the line I quoted which is very embarrassing:
I read that as you write tests to ensure things don’t change in the future 
I’ve been sitting trying to figure out how to respond thinking, “WTH is going on here…”
Anyway, yes, me too.
Yeah, most unit tests exist just to reduce the risk of regressions. As you yourself pointed out, they’re quite unnecessary otherwise.
lol, naw you wrote perfectly clearly, I just misread. I’m also on the last day of a week off where I didn’t write any code but blabbed a lot on here. My brain isn’t in tip-top shape atm.
If you want a more philosophical exploration of this topic, check out this Gary Bernhardt talk from a couple years ago.
https://www.destroyallsoftware.com/talks/ideology
The gist of the talk is that with respect to type systems and tests, static language advocates have an underlying assumption that correctness can be proved exclusively by categories, which is false in the case of most static languages because you can’t define categories as precisely as you would need to given the limits of their type system. Whereas dynamic language advocates have an underlying assumption that correctness can be proved by examples, which obviously is also not true.
To me, the conversation about equivalency of type systems and tests fell out of the mainstream maybe four or five years ago, where I think most people today think about the value of type systems in their ability to create more powerful language servers for your IDE.
Now, of course, after you watch the Gary Bernhard talk, you’ll notice the flaw in even the current dialogue that is equivalent to the garbage collection example he gave at the end of his talk. The implication that a type system is required to make a powerful language server implies that there exists no better language server algorithm that can power these predictions. I think some of the great work Mitch Hanberg on elixirtools/next-ls is proving that.
The way I personally evaluate this topic is what system Is the least tedious to maintain and what most reliably catches breaking changes as I modify my code base. I think this is why the JavaScript community has so widely adopted TypeScript given its sweet spot of type inference and catching function invocations that violate the type specification.
For me personally, I try only to write integration tests that are end-to-end and unit tests of pure functions. Those help me ensure I don’t break any functionality as I change my code, whereas type systems help me do code-level refactors behind the outmost API, where most structure is in-flux, without having to constantly rewrite/fix broken tests
I know and love this talk and have watched it several times (along with Gary’s other criminally under-rated talks that aren’t the “WAT”).
I have nothing against statically typed languages and I don’t personally believe that testing replaces types… at least not testing alone, but I really didn’t want to turn this thread into a debate 
I’ve played around with typed languages but have no professional experience with them and I haven’t even built a fleshed-out toy application with one. My questioned stemmed from the extreme stance that is taken online around static typing. In this particular case, I was talking about how I’ve read the phrase: “Static types replace a whole class of tests!” so many times online but examples of are never given (I never bothered asking because I didn’t want to get involved in a static typing debate on the internet). I was always skeptical and then I watched José’s talk where he said he doesn’t agree with this statement, so I was like, “Yay! Ok, so what are these tests people were writing that they stopped writing once they had types?”
I definitely see how it benefits LSPs. I guess it’s a “weird flex” as the kids say, but I don’t use them (though I love Mitch’s work in general).
I’ve seen lots of tests for typing in all different “untyped” languages (here are some examples in Rails’s ActiveRecord tests), but because it’s generally only useful where the (internal) interface is important you’ll see it almost exclusive in library code, rather than app code.
Yes, this is another point that rarely comes up in many debates: the difference between app and library code.
Thanks for the link to the AR tests!
Hello, and thanks for asking.
In my Elixir experience, I don’t miss a type system for the solo purpose of checking that the types of expressions are ok.
In fact, I never feared refactoring large amounts of code, and usually I get everything ok at first, or sometimes after fixing one or two type mismatches, which in general are very easy to find and fix.
I do not recommend to write test just to check for types. I think it is a nonsense.
Instead, write tests to be sure that the code does what is supposed to do, and type-checking will come along the way.
Obviously, if your test coverage is not wide enough, then you probably are not testing a part of the code where a type mismatch is hidden … and this is where a static type system will help you avoid these hidden type mismatches. But if someone is not covering well the code with tests, then probably they don’t care for that code’s quality too, so you get as much as you put in.
What I expect of a kind of static type system that is really worth to use is that of a dependent type system. I have no experience with these, but I suspect they may help avoid writing large swathes of tests in exchange of writing proofs about what is expected from the code. For example, I think this kind of type systems can avoid peppering the code with assertions by providing proofs about what we want to assert.
The advantage of proofs is that they ensure a kind of “100% test coverage” of the code you prove. However, some say proofs are frequently (generally?) more difficult to write in comparison to tests.
Property-based testing can help you more than case-based testing, because it automatically tests on a large range of inputs, thus raising coverage, however it cannot provide full guarantees like proofs do.
I think these are all tradeoffs, and I look forward one day to experiment with such a dependent type system, to have a more complete view of this topic.
Hope this helped you.
