(Although I'll follow Scott's suggestion of putting future discussion on
this just to [EMAIL PROTECTED], I thought Jon had an interesting
question)
Although I have a slightly different perspective from Scott, I think part
of his suggestion springs from working with the Xalan testing harness at
http://xml.apache.org/xalan-j/test/overview.html Being the primary author
on the Xalan API tests, I can answer Jon's question from my personal
perspective:
----
"Why didn't I start working with JUnit instead of creating our own testing
environment?"
----
First, I started the Xalan tests by revamping a system I had used for the
past half-dozen years on several internal software projects. When I
started adapting it for Xalan, I wasn't aware of JUnit, and Ant hadn't
really started yet.
I did review JUnit a while back, and took another look at it now. My two
main difficulties with it are it's limited logging abilities, and how it
feels like it's targeted very much at hardcore developers - and not at all
at quality engineers and other testwriters.
As far as logging goes, while there are a bunch of (some pretty nifty)
decorators and GUI testrunners, the basic logging is too simplistic. I
suppose for some tests, that's fine: developer 'X' writes unit tests for
their own code, which basically only has to do {new foo().doSomething();
assert(foo.OK()) }, but it feels limited for people who want to write
bigger test scripts, integration tests, and large-scale functionality
tests. Compare/contrast to org.apache.qetest.Reporter, which offers
multiple logging levels for various kinds of messages, and result states
from Incomplete/Pass/Fail/Error/Ambiguous.
Overall, JUnit feels very small scale, individual developer oriented. I
definitely get this feel reading their documentation: like how the Cookbook
starts off by using the debugger to test things. While I like how they've
worked in the doc on ways to get developer-based unit testing integrated
into the whole development process, I still found some of the doc a little
hard to follow for less experienced testwriters. (I know, I know, for all
3 of you out there who've read the Xalan testing docs, I'm not always much
clearer).
I wanted something that would produce more detailed reports, work better
for larger test cases, and was easier to present to, and be used by,
testwriters who might not be expert developers. In another (internal)
project I had fairly good success in training a large group of quality
engineers with little or no programming experience to write their own API
tests. One thing I am wondering about now is how to apply that idea to
open source, with a much different developer and user community.
----
Note: while that tries to cover Jon's specific question, there's plenty
more to discuss about both 1) what specific groups want as requirements,
and 2) how we make them work in our particular group's development
cycles... but for now, I'll continue that discussion on
[EMAIL PROTECTED], and invite anyone else on these other lists to come
on over...
- Shane
---- you: Jon Stevens <[EMAIL PROTECTED]> wrote ----
> What would it take to make JUnit address your needs?
>
> I'm tired of hearing people start new projects without also giving
details
> about exactly why they can't do the work to make existing projects more
> compatible for their needs.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
