On Sat, Feb 22, 2014 at 3:57 PM, Gregory Szorc <g...@mozilla.com> wrote: > On Feb 22, 2014, at 8:18, Kyle Huey <m...@kylehuey.com> 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? > > Possibly radical idea: patches are automatically audited to verify tests > actually test the new/changed code. If not, a giant flag is raised and > reviewers can act accordingly.
This doesn't even need code coverage analysis, -Wunreachable-code would do. Code coverage is useful for seeing what code needs more tests written. I think we used the code coverage data that choller collected a year or two ago to pinpoint some IndexedDB features that needed better testing, although I can't find the relevant bugs now. It's certainly not a panacea though. For one thing, just executing a line of code doesn't mean a test will fail if that piece of code is broken. I would love to have that data available for identifying what needs more focused testing effort though. - Kyle _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
