Hacker News new | past | comments | ask | show | jobs | submit login

It's funny you mention that you had difficulty having your team write tests. At my company, the CTO has difficulty writing tests and the team has consistently written adequate test coverage.

I fixed this in a new project by starting with jest [1] and failing the CI if the test coverage wasn't at 100%.

[1] : https://facebook.github.io/jest/

> failing the CI if the test coverage wasn't at 100%.

This is horrible advice and should never be followed.

Why? It's not hard to do if you start a fresh project.

Just because you have coverage doesn't necessarily mean that you have written good tests.

That being said, we do something similar where we require 80% coverage.

The difference between 80% coverage and 100% coverage is overrated. 80% is more than sufficient, i'd even go ahead and say 70% is better.

100% goes into "change detecting test" territory. There's also the time aspect: going from 0-70 is not hard, 70-100 is extremely time consuming, and often not worth the effort.

Monitoring is a way more efficient tool at catching issues.

While I agree with 70% is about the sweet spot, it really depends on the tools you're using.

We've found that with using Jest and just doing snapshots you can get to 70% without actually testing any of your others methods, hence the 80% coverage requirement.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact