@sph you rely on good unit tests for what? You made the refactoring, now all your tests fail, if you're lucky, with stacktraces. Now what?

@jonn exactly what I would have done if I had types or used Dialyzer: fix the refactored code until tests pass. That assumes good testing methodology, i.e. that your tests don't need to be rewritten after a refactor. If they do, you're testing at too low level and/or need better public interfaces (or in this case, behaviours)

@sph the whole premise of refactoring is changing of interfaces and contracts within your codebase.

For example you went from urlsafe base64 for something to hashing it (because, say, you figured that you can't afford to transfer full data or that you don't need to).

Likely your functional tests shouldn't be changed, your e2e tests shouldn't be changed, but your invariant tests *will* change as the result.

In our example, before the refactoring, you had tripping invariant for the data format discussed, so, responsibly, you should've checked for this invariant, after — you don't.

But anyway, I don't want to argue. Your whole argument is "I'm careful that's why my refactorings are complete". Good for you, I'm not careful and even when I am, I can't ask all my colleagues to be too.

@jonn arguing is certainly not what I wanted to do, but just offer another data point. Re: testing, may I recommend the talk "TDD: where did it go all wrong?" by Ian Cooper. It's a long talk full of radical ideas, and one they promote is that unit tests are the first to break during refactoring. Their suggestion is to write tests BEFORE refactoring, change anything you need, and then throw away those tests.

In any case, Dialyzer is good to have. I just wish it were a little more ergonomic.

@sph regarding unit tests: I think it must be clear that unit tests (case tests) are *amazing* tool for just one purpose: testing for regressions. You can't test for regressions before they happen.

You can test for some edge cases, but thinking a bit harder may lead to a realisation that these edge cases are unified into some invariant, so then we can start using property testing and model checking to test invariants, including #e2e.

I think that without dialyzer refactoring #elixir codebases is hell (to an extent where I think that it shouldn't be done!), whereas with dialyzer it's just pain sprinkled with suffering.

Regarding dialyzer's ergonomics, I'm not sure what's the problem to be honest. Yeah, I look up how to read the errors and have to manually untangle the error reports every time I get a non-trivial amounts of errors, but I think that the biggest problem of dialyzer is false negatives due to limitations.

BTW, state of the art report on dia- and #gradualizer: https://piped.kavin.rocks/watch?v=0Oo8ZBAsKVs