A huge task ahead...
Jacques
From: "Adam Heath" <doo...@brainfood.com>
Scott Gray wrote:
Additionally, just because a line has been noted in cobertura, doesn't
mean all variations have been tested. Consider the case that some
condition is doing some kind of pattern match, or looking at
Collection.contains or Map.containsKey. It's much simpler to verify
that everything is tested when it is done explicitly.
Okay I see what you mean now, it's a bad thing that coverage is reported
without explicit thorough testing. Even though the indirect coverage is
still better than no coverage whatsoever.
As a better example, let's say that there is only 10% coverage on the
entire ofbiz code base. But base has 100% coverage. That other 90%
of untested code may test parts of base that may not work, and would
break the higher-level code.
It's easier to write tests that are close to the code being tested.
Trying to tweak a high-level test to make certain all low-level code
is wrong is very very difficult.
Plus, if a typo gets introduced in one of those map keys, it might not
be detected until much much later in time, when explicit tests are not
used.
In my opinion, as each new component is activated in the ofbiz system,
it should have it's own set of tests that move it close to 100%
coverage. So, I can test just base, and get 100%, then base+sql, and
get 100% on base+sql, then base+sql+entity, and get 100% on
base+sql+entity, and so on. You want to make certain that earlier
components are correct before utilizing later ones, or the entire test
run may fail spectactulary.
