I very, very strongly disagree with this. If you’re doing unit testing right, type or not will not make a difference. You’ll be writing the same tests: proper specs will test the public surface of your code and it’s expectation. That is implementation agnostic.
There are a few exceptions in what is even possible to test: if your type system does not allow null, you don’t have to test the null case, obviously. If you’re using a type system that allows proofs by induction, certain edge cases won’t even be testable if you tried.
None of those things apply to type systems like C#, Java or TypeScript (yet. It’s at least getting strict nulls eventually. Flow has that now. And that’s still a far cry from Elm or Haskell style type systems).
If you look at a test and you’re telling yourself: “I would not have written this test if it was for a type system”, the test is probably wrong. If you’re looking at a test suite and telling yourself: “I wouldn’t have written nearly as many tests in this other language”, you’re probably TDDing wrong and not testing requirements/specifications and instead either doing integration testing or testing implementation details.