Even if you are working on relatively small or personal project, testing for a 100% coverage/mutation is ok I guess. I do this on my personal projects, and obviously I am testing core language features like you (testing if my methods throw a TypeError if they get something else than a Number for example). But overall, it is never wasted.
The only case where I feel loosing time is when I go on with a complex logic, immediately cover it with tests, only to see that the API does not feel good and changing it again. This is frustrating, but I would say that I would never came up to the conclusion of reworking the API if I was not sure my methods worked correctly.
Some other times, I will completely ignore tests when starting a library up to a point when I feel comfortable with the API. Sometimes it feels better like that but I do not have a fixed procedure...
Even if you are working on relatively small or personal project, testing for a 100% coverage/mutation is ok I guess. I do this on my personal projects, and obviously I am testing core language features like you (testing if my methods throw a TypeError if they get something else than a Number for example). But overall, it is never wasted.
The only case where I feel loosing time is when I go on with a complex logic, immediately cover it with tests, only to see that the API does not feel good and changing it again. This is frustrating, but I would say that I would never came up to the conclusion of reworking the API if I was not sure my methods worked correctly.
Some other times, I will completely ignore tests when starting a library up to a point when I feel comfortable with the API. Sometimes it feels better like that but I do not have a fixed procedure...
Interesting point, I've definitely had issues with locking down an API and could definitely see how that leads to wasted work.
As with most things, then, "it depends".