Testing Imbalance: 13 Tests Per Method, But 71% Coverage Concentrated in Top 20%

By shrijeetverma13 · July 19, 2026

This analysis maps 3,386 unique tests across 250 production methods in a large codebase, revealing severe coverage concentration. While the average method…

The overall ratio of unique tests to unique production methods is 13.54 to 1. There are 3,386 unique tests compared to only 250 unique production methods, meaning each production method is associated with roughly 13.5 different tests on average.

The production method covered by the most test cases is 'AsyncExitStackMiddleware. call ', with 2,811 unique test cases. It's closely followed by 'FastAPI. call ' (2,794 tests), 'app' (2,659 tests), 'lenient issubclass' (2,411 tests), and ' extract endpoint context' (2,362 tests). A horizontal bar chart highlights the top 15 most-tested production methods, making it easy to compare coverage levels across methods.

Out of 250 unique production methods, 14 are covered by just a single test, marking them as high-risk coverage gaps. These include methods like 'main', 'DefaultPlaceholder. bool ', and several UploadFile methods (close, write, read, seek), along with ModelField.serialize, evaluate forwardref, HTTPBearer. init , and AsyncLiftContextManager. aexit . A bar chart highlights the 15 least-tested production methods, making it easy to spot where additional test coverage is most needed.

The test 'tests/test union body discriminator.py::test discriminator pydantic v2 run' maps to the most production methods, with 106 unique methods connected to it. This is followed closely by tests in test schema extra examples.py, which map to 101 and 95 methods respectively.

The analysis generated a chart ranking production methods by the number of distinct tests applied to each, which helps identify where testing redundancy may exist. Methods appearing near the top of the chart with high distinct test counts are the ones most likely to have overlapping or duplicated testing efforts worth reviewing.

Test-to-method mappings are highly concentrated among a small group of top production methods. Out of 250 total production methods and 84,806 distinct test mappings, the top 10 methods alone account for 28.9% of all mappings, while just the top 20% of methods (about 50 methods) account for 70.9% of all mappings. The single most-covered method, AsyncExitStackMiddleware. call , has 2,811 distinct tests mapped to it - far more than any other method. This pattern shows that testing effort is heavily focused on a relatively small set of critical methods rather than spread evenly across all 250 methods.

The analysis extracted class names from the production method field and identified the top 15 most frequently referenced classes across all test mappings. A horizontal bar chart was generated showing each class ranked by the number of mappings it appears in, along with its percentage share of the total. Supporting data tables were also produced to accompany the visualization.

Good news: each production method in your dataset is uniquely associated with only one repo name. This means there are no anomalous production methods that appear mapped to test names from multiple repositories, indicating clean and consistent naming conventions across your repos.

A grouped bar chart was created showing the number of unique test names versus unique production methods for each repository, helping to visualize which repos have more tests relative to their methods (or vice versa). The chart and accompanying data tables let you quickly spot repositories where test coverage is disproportionate to the number of methods being tested.

The test files with the broadest production method coverage are completely different from the test files with the most repo diversity. The top test for method coverage is test tutorial002.py, which touches 130 distinct production methods, while the top test for repo diversity is test ws router.py, though it only spans 1 distinct repo. None of the top 10 tests ranked by method coverage appear in the top 10 ranked by repo diversity, showing these are two completely separate sets of tests.