4 ms·
I had a similar experience, you always get what you measure. IMO the best a approach is to first integrate the test coverage in the code reviews, cause there i
by pedro1976 8y ago
I had a similar experience, you always get what you measure.
IMO the best a approach is to first integrate the test coverage in the code reviews, cause there is no hard rule [0] and second write property-based tests [1].
[0] http://www.se-radio.net/2018/05/se-radio-episode-324-marc-hoffmann-on-code-test-coverage-analysis-and-tools/ http://www.se-radio.net/2018/05/se-radio-episode-324-marc-ho...
[1] Sample framework for JavaScript https://github.com/jsverify/jsverify https://github.com/jsverify/jsverify
- sethammons 8y agoI like the idea of property based testing, but have found that it obfuscated the test code, making it much harder to read (especially for new teammates). This was in Go, so maybe it had a lot more cruft around it than it would in something more functional or js.
- Vinnl 8y agoI prefer just setting coverage requirements to 100%, and give developers the freedom to mark code as ignored for coverage (e.g. /* istanbul ignore next */ for many Javascript applications). That way, the annotation is something that can be brought up during code reviews in case the reviewer does not agree with that not being covered, and it doesn't depend on the reviewer having to remember to run or look at a separate coverage report. (I wrote more about this here: https://vincenttunru.com/100-percent-coverage/ https://vincenttunru.com/100-percent-coverage/)