01-30-07 06:11 AM
<snip: confluence>
OK - I'll put a link to the apt generated html :-)
It opens directly from subversion anyways.
As soon as I find those extra 36 hours in the day, I'm
going to make an Eclipse plugin that is pulls xsd
template schemas from a (Maven like) repository and
automatically produces sample instance documents for
documenting in a standardized template format.
Then I need another mojo that produces corresponding
eclipse plugin documentation in a larger context.
Then we can keep documentation tied tightly to a
project, subversion it, and gain all the benefits I
put in the Eclipse Help System proposal.
<snip:testing>
The 100% method will be very straight forward once the
tooling is done. I'll hold off on discussing anymore,
because I want the paper to be the context for it.
The main thing I want comitters to understand is the
methodology. Doing the methodology by hand could be a
little tricky :-),
The other benefit is that there will be a clearly
defined unambiguous doable unit testing goal for the
project.
<snip: following in other's footsteps:>
Yeah - the unit testing lines to total code lines
ratio is slightly skewed right now :-)
So I would think of the checklist as reflecting the
goal and approach of where we want to be.
Personally I would also expect us to come together and
review and agree on a set of standards so that we all
do them.
That said the primary criteria should be for these to
make us more efficient, ofcoarse.
If you would like a hint besides the JUnit discussion
around the testing automation, check out:
www.agitar.com
www.junitfactory.com
These guys were also in the JUnit discssion btw :-)
Cheers,
- Ole
________________________________________
____________________________________
________
Have a burning question?
Go to www.Answers.yahoo.com and get answers from real people who know.
[ Post a follow-up to this message ]
|