xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shane_Curc...@lotus.com
Subject Re: Test Infrastructure Project Proposal - re:Jon & Ovidiu (& Paul)
Date Mon, 12 Feb 2001 22:11:51 GMT
(Only broadcasting on general@xml.apache.org)

---- you Jon Stevens <jon@latchkey.com> wrote: ----
> Again: don't create yet another project because the other one doesn't fit
> your needs today. Work with existing projects to make them fit your
needs.
> If they don't want you or the license is incompatible, then that is an
> acceptable reason to fork.

SC: I understand your idea here, and in general I *do* like re-using
existing things when it's practical.  However in this particular case, the
original implementation of the code I use for Xalan testing today dates
from 1991, so I wasn't creating something new, I was re-using something old
(it was actually in LotusScript, not Java, but a number of the methods
still have the same signatures even!)  And if an individual project really
wants to invent their own wheel, I don't think anyone else should try to
stop them.  If other people like the new wheel, they'll come use it, great.
If they don't, then everyone else can keep using the old wheels, no harm
done there, it's just that project's new wheel will probably get a bit
dusty... :SC

SC: addendum: and yes, I'm glad you brought up 'community', since it is
important in open source.  Although I should spend some time in the JUnit
community to see how it and they work, what I'd personally like to focus
most of my work on is the xml.apache.org community - and, as time permits,
the jakarta.apache.org community.  While the JUnit community may be able to
offer us valuable software, and certainly some valuable development process
ideas, for now I need to get my head around what the xml and jakarta
communities think about this stuff, so we can see where to go now. :SC

---- Ovidiu Predescu <ovidiu@cup.hp.com> wrote: ----
> I believe we should look at the merits of his framework before discussing
how
> or whether it can or should be integrated with JUnit. Your approach of
one size
> fits all doesn't always work.

SC: Good point.  Although I know I may not be explaining myself well today
(just came down with a cold) besides the fact I already had the code, there
are differences in what I want from what I see JUnit as doing.  Now to be a
good doobie, I should hang out over in the JUnit space and try it out and
see if we can make suggestions to each other; I just haven't had the time
yet.  Some people may not see 'not having the time' as an excuse, but hey:
that's another aspect to open source - people get to work on what they
want.  :SC

---- Ovidiu Predescu <ovidiu@cup.hp.com> wrote: ----
> Shane, do you have the code in a shape that could be posted on the Web
for
> others to review? I'm very much interested in a framework that has the
> capabilities you describe.

SC: Um, sure - it's open source... just go read it.  8-)

<digression>
(So a separate question that I've always been curious about: how do we get
better user docs for open source projects?  Many projects I've seen still
feel very technical and unforgiving to newbies, which can make it hard for
new people to break in.)
</digression>

My documentation, such as it is, should be easily browsable with your
favorite software at:
  http://xml.apache.org/xalan-j/test/overview.html

The source code is not currently shipped with the Xalan distributions; it
is however all checked into the xml-xalan\test directory in the same
repository.  You can browse the repository on the web (somewhat slowly) at:
  http://xml.apache.org/websrc/cvsweb.cgi/xml-xalan/test/
or simply get a source-code-only snapshot of the whole xml-xalan tree,
tarr'd nightly, at:
  http://xml.apache.org/from-cvs/xml-xalan/

Re: Ovidiu and Paul R: basically, this is a generic testing framework
designed for use by either quality engineers or developers to write any
sorts of automated tests for their product.  It also has an implementation
for testing Xalan in various configurations.  Some of the areas I have not
focused on yet are Ant integration (should be fairly simple for the basics)
and other 'pretty' testrunners, and building server-based testing tools
(eg. for servlet, webserver, etc. testing on multiple machines).  In some
ways until I checked in org.apache.qetest.Testlet, it has a focus towards
people who are going to sit down to write a bunch of automated tests to get
checked in, as opposed to individual developers working on quick&dirty mini
unit tests alone, but with a little more doc and review of
Testlets/Datalets, I think it can serve both communities.

- Shane


Mime
View raw message