The state of JavaScript and TypeScript test coverage
The state of JavaScript and TypeScript test coverage
We pulled the public test coverage number for 241 JavaScript and TypeScript repositories that publish a coverage badge (Codecov, Coveralls, or SonarCloud), then read each badge to get the real figure. Here is what the data looks like, and why the headline number is a trap.
The headline
- Median line coverage: 96 percent.
- Mean line coverage: 86.4 percent.
- 90.5 percent of these repositories sit above 60 percent coverage.
- The split between JavaScript and TypeScript was almost even: 121 JavaScript, 120 TypeScript.
If you stopped reading there, you would conclude that JavaScript and TypeScript projects are extremely well tested. That conclusion is wrong, and the reason is in how the sample was built.
The distribution
Out of 241 repositories with a readable coverage number:
| Coverage band | Repositories | Share |
|---|---|---|
| 0 to 25 percent | 10 | 4.1 percent |
| 25 to 50 percent | 6 | 2.5 percent |
| 50 to 75 percent | 24 | 10.0 percent |
| 75 to 90 percent | 43 | 17.8 percent |
| 90 to 100 percent | 158 | 65.6 percent |
Two thirds of the sample is above 90 percent. The mean (86.4) sits well below the median (96) because a small tail of low-coverage repositories drags the average down while most of the mass piles up near the top.
The selection bias is the story
Here is the part that matters: a repository only enters this dataset if it publishes a public coverage badge. That is a strong filter. Teams that wire up Codecov and put a badge in the README are, almost by definition, teams that already care about coverage and have already done the work. The badge is a flex. You do not advertise a number you are ashamed of.
So this is not "the coverage of JavaScript and TypeScript projects." It is "the coverage of JavaScript and TypeScript projects whose maintainers chose to show their coverage." Those are very different populations.
Look at where the gap actually lives. Only 15 of the 241 repositories (about 6 percent) sit in the 40 to 65 percent band, the range where there is real room to improve. And the most popular project in that band has just 276 stars. The recognizable names are almost all clustered up near 100 percent. In other words, the projects with a meaningful coverage gap are, with very few exceptions, not the ones publishing a badge.
The interesting repositories are the ones that are not in this dataset: the private company codebases and the open-source projects with no badge at all. Those are the projects where coverage is an unknown, often because nobody has measured it recently, and where the real number tends to be a lot lower than 96 percent.
What we take from it
- A public coverage badge is a signal of an already-tested codebase, not a representative sample. If you are benchmarking your own project against "the ecosystem," do not anchor on 96 percent. Anchor on 80, which is the practical target for most teams.
- The honest way to know your number is to measure it, not to guess from public examples. Most teams have never run a clean before-and-after on their own repository.
- The gap that matters is invisible in public data. The codebases that would benefit most from a coverage push are exactly the ones that do not publish a badge.
If you want your own number, you can check a public repo for free or run a read-only scan on one private repo. We clone it, run its suite, and report the real figure plus the files where new tests would cut the most risk.
Method, briefly
We searched public READMEs for Codecov, Coveralls, and SonarCloud badge links, kept the JavaScript and TypeScript repositories, and read the coverage value each provider exposes. We recorded 241 repositories with a readable number. This is a convenience sample of badge-publishing projects, not a random sample of all repositories, and the selection bias described above applies throughout.
The full per-repo dataset and a downloadable CSV live on the research page, free to reuse under CC BY 4.0.