We could but I don't think it would help us track progress very well, there are just too many tests that need to be created. A good start IMO would be to go through every open bug and create a test case that reproduces the problem and attach them as patches to be committed with the fix. Tackling those would at least prevent known bugs from recurring. Other than that I think people will just proceed with creating tests for the areas that concern them most.

Regards
Scott

On 11/12/2009, at 10:13 PM, Jacques Le Roux wrote:

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.





Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to