juddi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Jack" <aj...@TrySybase.com>
Subject RE: [juddi-Developers] using junit
Date Fri, 30 May 2003 06:22:06 GMT
	Hi Andy, to be honest I haven't given it much thought since coming to
	the conclusion that jUDDI needs a JUnit test suite. I like the fact that
	JUnit is well documented, open-source and has such a large installed
	base. The fact that JUnit also includes Ant tasks is another bonus IMHO.

Not sure I follow that last statement, but ant can run junit, and junit can
even run (test) ant tasks [not that you have any, I believe.]

What is key about junit (IMHO) is that tests become "build time verified
assertions", and that is 1000 times better than documentation. If possible,
tests need to exercise each 'API' to a class, in part to ensure it never
changes. Tests become user advocates.

	As far as how the jUDDI test suite is layed out... I am thinking of
	creating different TestSuite for different application layers. jUDDI can
	be broken down into a Service layer, a Persistence layer a Transport/XML
	Marshalling layer (more?). We could also create TestSuites based on the
	different 'modules' ... Authenticator, DataStore, UUIDGenerator, etc.
	There's nothing wrong with lots of cross testing.

I would start "very small" and work big. A test XTest.java for class X.java
that tests all the main method, even (say) that X('fred') can assert that
"fred".equals(X.getName()) is invaluable. I think these sort of tests are
often overlooked, and are critic, especially for a data object centric
product like a UDDI server.

That junit test runners will go out and find any *Test.class and attempt to
run it as a test, is very powerful, 'cos adding tests becomes so easy. As
such, I don't  think you need to give "lay out" much thought (just stick
things in src/test -- usually in a package parallel to the package you are
testing, 'cos this allows test access to package only methods/variables).

As such, I'd not think about layout so much as coverage -- ensuring you test
every thing you possibly can. That is hard, but doable with discipline. Bug
fixing ought start with adding a test (that demonstrates the problem) then
fixing it, and seeing the test pass. A build ought be compile/test/package
w/ no way to get to the third w/o passing all tests. Small investment in
tests pays off huge in having "a dispassionate set of eye monitoring your

That all said, where junit may not help you -- and where you have a need --
is in integration testing, and with "environmentally sensitive testing". At
the highest level you need a datastore and a web server in the environment,
against which to test, and build time isn't a good time to try to integrate
with those things.

Smart use of ant against a known 24x7 resource (DB/server) could allow a
build/test/package/deploy/test cycle, but it'd likely fail. You might wish
to (after a while) look hard at structuring your code dependencies so you
can test things in a unit test fashion, i.e. test queries w/o a DB to test
against, test marshalling in/out of memory, but that is probably for later

	Just some random thoughts. You can never have enough tests.

Amen. ;-)



View raw message