[22:09:28] https://coverage.toolforge.org/charts/mediawiki.svg is looking good! [22:25:29] Krinkle: when does the trend line hit 80%? Another 12 years or so? [22:26:01] Up and to the right is good though! [22:26:31] bd808: A big part of the slow growth is also due to us moving the "best" code out of core into libs [22:26:42] which have virtually all ~100% coverage [22:26:52] and we still go up despite that [22:27:09] ah. that would be interesting to figure out how to show. The cumulative gains [22:27:31] data at https://doc.wikimedia.org/cover/ [22:29:11] https://coverage.toolforge.org/charts/CentralAuth.svg [22:29:21] if only we kept the stats for libs [22:29:23] it's only core + ext [22:29:27] being scraped [22:29:53] but one could add up all the file counts from libs as they are today, and assume there were 0 in 2017 [22:30:02] and assume a linear increase [22:30:11] see where that puts us [22:30:25] we started moving libs out in 2014, but yeah [22:30:37] right [22:30:47] also, remember we're pretty strict/conservative in what we count as coverage [22:30:52] we only count @covers attributed code [22:31:20] right. intentional vs incidental [22:31:47] https://www.mediawiki.org/wiki/Library_infrastructure_for_MediaWiki -- that was so long ago but also recent somehow in my mind [22:32:12] high-level integration tests like performing edits aren't so much incidental imho, but it's thus basically counting unit tests only, where I'd count "integration tests for X and deps" as doubling as a unit test for "X" (without deps). [22:32:34] where it has a dedicated test suite per low-leel sub component [22:32:57] we coudl run it once without that and see if any obvious things stand out that we should claim in an integration test if we feel they don't (also) need dedicated unit tests. [22:33:26] Iv'e mostly ripped out the (imho, absurd) pattern of limiting it to individually listed methods [22:34:02] https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Cite/+/982945 with verbose commit msg as to why [22:34:51] https://gerrit.wikimedia.org/r/q/is:merged+message:Widen [22:35:41] it meant that during refactors lots of private methods become uncovered or are never listed in the first place, or (just as bad) cause CI to break if you rename a private function that was named in @covers. [22:37:27] :nod: seems reasonable to me [22:37:36] It's sometimes useful if you have a god object and need the precision, but just because we can doesn't mean we always should. [22:38:21] still some 300 files in mediawiki-core/phpunit that match `@covers .*::` [22:39:19] things we miss having Google CodeIn to help grind down...