Discussion on: Achieving 100% code coverage will make you a better developer. Seriously.

View post

[The] author made a point that too many new developers are too obsessed with 100% test coverage and that it can end up eating up too much development time. The authors point was you should test the most important parts and be happy with maybe 80% test coverage in order to save some time.

I have no problem with 100% test coverage in some cases. I have 100% coverage in a library I wrote, as it's easy to test, I wrote all of the code, and it adds value to test everything.

That's the key thing to me - how much value does adding more tests add?

If I am using a framework like Django, testing that Django isn't broken doesn't add value to me, as it has its own test suite.

from foo.models import Foo

def test_foo_name_matches_bar():
    my_foo = Foo(name="Bar")
    assert my_foo.name == "Bar"

Congrats - Django isn't broken. Completely useless test, IMO.

Also another issue with 100% coverage is when one thing changes about your code you have to reevaluate your tests and make changes and maybe add more etc.

You should refactor tests just like you refactor code. Don't get sucked into the sunk cost fallacy that just because you wrote some tests at some point and later realize they don't bring value, they are untouchable because you spent x hours writing them.

If they are harder to maintain than the value they bring, re-write or even delete them. If you're confident with your code, even with the coverage dropping a bit, that's fine with me.

Basically, be pragmatic, not dogmatic, when it comes to testing (and most other disciplines).