Unit tests are designed to test the developer's code logic. You always aim to cover 100% of your code, but there is limits to what should be tested.
I tend to not test logic of things handled by a framework. For example: Django and its auto-generated admin view. Unless you extend the code with your own implementation, you can assume the team behind already provide a "flawless" logic.
You should also evaluate what are the needs and the aim of your project. If you work for a startup, wasting too much resources on useless tests is bad. If you project on a project that is daily used by 100k+ users, then having something robust, reliable and fully tested is mandatory and the budget to support this is consequent. There is a point where more tests won't add any value and you should know that threshold.
I prefer doing unit tests way before doing any integration tests. Integration tests are black box tests to make sure your use cases are fine, but if the logic behind is buggy things will start to go sour.
Great answer, thanks for your perspective! It makes sense that integration tests need your code logic to be sound already. I think part of my issue is that I'm not working for anyone at all, these are just hobby projects, and perhaps striving for fully tested isn't a good use of time when trying to just produce something working.
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...
Unit tests are designed to test the developer's code logic. You always aim to cover 100% of your code, but there is limits to what should be tested.
I tend to not test logic of things handled by a framework. For example: Django and its auto-generated admin view. Unless you extend the code with your own implementation, you can assume the team behind already provide a "flawless" logic.
You should also evaluate what are the needs and the aim of your project. If you work for a startup, wasting too much resources on useless tests is bad. If you project on a project that is daily used by 100k+ users, then having something robust, reliable and fully tested is mandatory and the budget to support this is consequent. There is a point where more tests won't add any value and you should know that threshold.
I prefer doing unit tests way before doing any integration tests. Integration tests are black box tests to make sure your use cases are fine, but if the logic behind is buggy things will start to go sour.
Great answer, thanks for your perspective! It makes sense that integration tests need your code logic to be sound already. I think part of my issue is that I'm not working for anyone at all, these are just hobby projects, and perhaps striving for fully tested isn't a good use of time when trying to just produce something working.
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".