Sure Scott,
Good recommendation, I will remember...
BTW, we could already open an umbrella issue in Jira and add subtask as things
go on?
I can't see a better way to coordinate this work
Jacques
From: "Scott Gray" <[email protected]>
Huge tasks are prone to failure, what we really have is a lot of
little tasks ahead. If you're writing some code, think about writing
the tests that should code along with it. Hopefully it'll become so
common place that anyone who doesn't do it will just look silly.
Regards
Scott
HotWax Media
http://www.hotwaxmedia.com
On 11/12/2009, at 8:59 PM, Jacques Le Roux wrote:
A huge task ahead...
Jacques
From: "Adam Heath" <[email protected]>
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.
