On Saturday 2014-02-22 15:57 -0800, Gregory Szorc wrote: > On Feb 22, 2014, at 8:18, Kyle Huey <[email protected]> wrote: > > If you needed another reason to follow the style guide: > > https://www.imperialviolet.org/2014/02/22/applebug.html > > > > Code coverage would have caught this as well. > > The time investment into 100% line and branch coverage is debatable. But you > can't argue that code coverage has its place, especially for high-importance > code such as crypto. > > AFAIK, our automation currently does not collect code coverage from any test > suite. Should that change?
There was some automation running code coverage reports (with gcov, I think) for at least reftests + mochitests for an extended period of time; I found it useful for improving style system test coverage while it was running. I'm not sure how strong our commitment is to keeping such tests running, though; I frequently have to defend the tests against people who want to disable them because they take a long time (i.e., a long time for a single test file, which sometimes leads the tests to approach the per-file timeouts on slow VMs) or because they happen to exhibit the latest JIT crash frequently because they run a lot of code. I'm worried we're moving to a model where tests need to have active defenders to keep them running (even though that isn't how features on the Web platform work), because we blame the old test rather than the new regression. -David -- 𝄞 L. David Baron http://dbaron.org/ 𝄂 𝄢 Mozilla https://www.mozilla.org/ 𝄂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914)
signature.asc
Description: Digital signature
_______________________________________________ dev-platform mailing list [email protected] https://lists.mozilla.org/listinfo/dev-platform
