Thanks a lot for chiming in @Y0hy0h and @joakin! I really appreciate the quotes and examples!
I see what you mean when you say that types can’t prevent all bugs. I agree with testing complex logic. At the same time, I’m not sure if simple functions should be tested.
For example the addTwo i = i + 2 function is something that I prolly would not test (even with a fuzz test). The types would not prevent me from writing addTwo i = i + 100. But is a test needed?
In the addTwo case I guess the test could save me from distraction. But I guess writing the correct implementation is easy. Also, what the function does can be deducted from the name and the types.
Kent Beck in Extreme Programming says
It is impossible to test absolutely everything, without the tests being as complicated and error-prone as the code. It is suicide to test nothing (in this sense of isolated, automatic tests). So, of all the things you can imagine testing, what should you test?
You should test things that might break. If code is so simple that it can’t possibly break, and you measure that the code in question doesn’t actually break in practice, then you shouldn’t write a test for it…
Testing is a bet. The bet pays off when your expectations are violated [when a test that you expect to pass fails, or when a test that you expect to fail passes]… So, if you could, you would only write those tests that pay off. Since you can’t know which tests would pay off (if you did, then you would already know and you wouldn’t be learning anything), you write tests that might pay off. As you test, you reflect on which kinds of tests tend to pay off and which don’t, and you write more of the ones that do pay off, and fewer of the ones that don’t.
That’s why I’m wondering if simple stuff should be tested. If not, what is simple and what not in Elm in your opinion?