It seems like you're very passionate about testing and programming, Daniel. I don't want to seem like an asshole, however, my twelve years experience in the industry as a developer has time and time again shown that 100% code coverage is not worth striving for.
In the early days of my career, I used to think you had to aim for 100% code coverage. That is what developers used to be told you had to aim for. But, once you reach a certain number (70-80% approximately) anything beyond that becomes increasingly difficult to achieve (the last 10% takes 90% of the time).
I think you and everyone else would agree that any tests are better than no tests. That aiming for an achievable and realistic target of say 70% is better than not focusing on tests at all. The issue with aiming for 100% coverage is developers inevitably will start to take shortcuts as they become fatigued with striving for 100% (which is quite difficult to do).
Instead of writing quality tests, developers will start writing tests for the sake of bumping up numbers in the coverage report. As an industry, we do not do enough to educate developers on how to write good tests, we just tell them to do it and leave them to their own devices (at least, in the front-end space we do).
In the webspace, the ecosystem is comprised of packages from Npm. It is not uncommon for a modern application to have tens of these Node packages, each with their own dependencies. If you are aiming for 100%, it is unavoidable you will be writing tests for these dependencies, having to mock them to get your tests to work and inevitably, testing packages that might already have tests.
Not to push my own agenda or advertise my own articles, but I wrote a comprehensive guide to unit testing on the front-end not too long ago. In my article, I have a section on writing good unit tests, advocating for developers to not just write tests, but spot bad code and refactor it. Testing bad code doesn't make it any better or safer, but bad code without tests makes it harder to refactor it.
Not sure if you’re just trolling or not, but with my FIFTEEN years of experience in the industry, I’m curious why you’d assume I’m not experienced in the topic I’m writing about 😉
It’s not that I disagree with what you’re saying, but I think you missed my point: as someone who has spent years teaching TDD and software design, I know how important it is to have clear goals that people can aspire to. With good TDD practice, 100% code coverage is straightforward and can even lead to quicker software development.
I enjoyed your article about unit testing. I’d be interested to hear what you think of my book, Mastering React Test-Driven Development. Let me know your feedback if you do read it.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
It seems like you're very passionate about testing and programming, Daniel. I don't want to seem like an asshole, however, my twelve years experience in the industry as a developer has time and time again shown that 100% code coverage is not worth striving for.
In the early days of my career, I used to think you had to aim for 100% code coverage. That is what developers used to be told you had to aim for. But, once you reach a certain number (70-80% approximately) anything beyond that becomes increasingly difficult to achieve (the last 10% takes 90% of the time).
I think you and everyone else would agree that any tests are better than no tests. That aiming for an achievable and realistic target of say 70% is better than not focusing on tests at all. The issue with aiming for 100% coverage is developers inevitably will start to take shortcuts as they become fatigued with striving for 100% (which is quite difficult to do).
Instead of writing quality tests, developers will start writing tests for the sake of bumping up numbers in the coverage report. As an industry, we do not do enough to educate developers on how to write good tests, we just tell them to do it and leave them to their own devices (at least, in the front-end space we do).
In the webspace, the ecosystem is comprised of packages from Npm. It is not uncommon for a modern application to have tens of these Node packages, each with their own dependencies. If you are aiming for 100%, it is unavoidable you will be writing tests for these dependencies, having to mock them to get your tests to work and inevitably, testing packages that might already have tests.
Not to push my own agenda or advertise my own articles, but I wrote a comprehensive guide to unit testing on the front-end not too long ago. In my article, I have a section on writing good unit tests, advocating for developers to not just write tests, but spot bad code and refactor it. Testing bad code doesn't make it any better or safer, but bad code without tests makes it harder to refactor it.
Not sure if you’re just trolling or not, but with my FIFTEEN years of experience in the industry, I’m curious why you’d assume I’m not experienced in the topic I’m writing about 😉
It’s not that I disagree with what you’re saying, but I think you missed my point: as someone who has spent years teaching TDD and software design, I know how important it is to have clear goals that people can aspire to. With good TDD practice, 100% code coverage is straightforward and can even lead to quicker software development.
I enjoyed your article about unit testing. I’d be interested to hear what you think of my book, Mastering React Test-Driven Development. Let me know your feedback if you do read it.