1. One of the steps into achieving the 100% coverage rule is to start with a better design. E.g. many times setter and getters are considered trivial to test and thereby causing people to skip testing them and thus lowering the coverage. the first step however should be to eliminate as many public access paths into the class as possible and many times the (automatically?!) added getter and setter should not even be there.

    In that regard I would love a language/compiler that allows me to annotate classes as Data Structures, DTO’s or Active Records and then would constrain me in adding to many or the wrong functions. That would (at least that is what I hope for) significantly reduce the effort it would take to achieve 100% coverage because the classes are better structured, lean and maintainable.

    Erno de Weerd

  2. Agreed, the best way to improve coverage is to write less code. For Java, there are frameworks like lombok or JSR 305 that allow adding certain constraints and automated code generation for dto, immutable, singleton patterns. I personally love 305 (but the spec is dormant right now) and am a bit weary about lombok because it requires a bit too much voodoo magic under the hood.

    Getters/setters and constructors are usually implicitly covered in the tests. In my example the person getter and setter is still covered. Although not explicitly asserted, tests will still break if they don’t work correctly.


Comments are closed.