Lately I’ve been having a bit of a crisis when it comes to unit testing in a typed functional language like Elm.
Thing is types already cover a lot of ground. Also, the fact that functions tend to get really small and declarative encourages me not to cover them with tests at all. As a matter of fact, I’m not sure what testing a small declarative function would get me besides making me think twice by writing the same logic twice: once in production code and once in test code. Especially because that would come at the cost of having to maintain the tests afterwards.
I guess this issue is connected with the fact that I’ve been doing type driven development and not test driven development in Elm. In other words, I have to justify to myself what’s worth covering with tests when the production code is in place (and likely works since it compiles).
Since small declarative functions seem not worth testing, I’ve considered testing bigger units (more functions together). But then I would have to setup more stuff to be able to assert. And again, I have the feeling that it’s not worth it.
To conclude, I don’t feel I need to test drive Elm cause I can type drive. I don’t feel I need to cover small declarative functions because they are straightforward. I’m not sure covering bigger units pays off. Also, I don’t want to end up with a lot of tests that don’t really provide value and I need to maintain.
I’d love if you could share your reasons for testing in Elm and how you do that?