juddi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From svi...@attbi.com
Subject RE: [juddi-Developers] using junit
Date Fri, 30 May 2003 08:25:10 GMT
My apologies for not being clear ... I was a little rushed :)

What I meant was, other than recognizing the fact that jUDDI really needs a
'test' suite and that it should be implemented with JUnit.  I haven't given it
any serious thought about how to begin to implement it.  I do believe that it
should be approached with some sort of coverage plan though. Also, most of the
jUDDI codebase can be tested without a remote db server or web server.  (an HSQL
db/datastore can be used to test JDBC code on the local machine).

We don't have to embark on a huge effort to build an complete-coverage JUnit
test suite ... but would be nice to have the process to add tests periodically,
simply and organized manner.

:)

Steve
> 
> 	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
> changes".
> 
> 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

> stages.
> 
> 	Just some random thoughts. You can never have enough tests.
> 
> Amen. ;-)
> 
> regards,
> 
> Adam
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: eBay
> Get office equipment for less on eBay!
> http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
> _______________________________________________
> juddi-developers mailing list
> juddi-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/juddi-developers



Mime
View raw message