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 13:30:05 GMT
Actually, the 'suite' I meant was a JUnit org.junit.framework.TestSuite

I'm mostly interested in unit testing. I also want to keep things simple and
keep test code separate from what ends up in the juddi.jar. That said, all types
of testing is good and I would prefer that it uses JUnit and can operate in an
automated build process (i.e. Any script). I'd rather be keep it simple by using
the JUnit Ant task feature. 

I like the idea of running tests from within an IDE (I use Eclispe and IDEA) and
 JUnit's supplied graphical test runner is nice too but our build/test process
must work with Ant and be able to run from the command line. Everything else is
simply just a nice-to-have (IMO).

Also, incorporating an HSQLDB db (hsqldb.jar) and using the jUDDI supplied
ConnectionPool (i.e. juddi.useConnectionPool=true property) should allow us to
create a very comprehensive TestSuite of org.juddi.datastore.jdbc unit tests.

Most of the bugs we've seen required changes to either the org.juddi.datatype
package, the org.juddi.datastore.jdbc package or org.juddi.parser pacakge. So,
minimally, I'd like to see one TestSuite each of the following jUDDI packages
(and any subpackages):

   org.juddi.datatype
   org.juddi.datastore.jdbc
   org.juddi.parser
   org.juddi.registry

...each TestSuite would contain a one TextCase for each class in the package.

It's a start.

Steve
> 
> 	junit probably will not help us with all the tests, we still need DB 
> tests
> 	and UDDI4J test clients separately. hmmm.. may be if we have all of them 
> as
> 	junit tests, but separate them as 2 groups, one testsuite that holds the
> 	tests that can be run nightly and which doesn't involve any DB process 
> and
> 	the other testsuite which can be used by developers in a completely
> 	installed environment.
> 
> I once tried a naming convention for test suites (AllTests.java for
> standalone unit tests, and EnvDependentTests.java). I combined these into
> high level suites. That said, since using Eclipse to run tests (it does a
> class search, it doesn't need to use suites) and since using Centipede/Ant
> to build/test (similar approach), I've pretty much given up on them.
> 
> If by "suite" you meant directories, that makes sense. Centipede will look
> at src/test and run junit on all tests in there, so you could put the
> environment dependent tests into third directory. Me, I kept them in
> src/java -- 'cos they only get run by me, from the JUnit GUI, when I need to
> run them. Not ideal, but better than not having them.
> 
> Much as I think you need a site (perhaps w/ automated access) for
> interoperability testing, I suspect that'd be hard work to attain
> (resources/access/automation/management). I doubt it'd pay off near as much
> as changing the code to be more unit testable. For example, have code to
> process a query (perhaps generate SQL, or whatever) even if you can't apply
> it to a DB for SQL verification. Also, have a 'TestDataStore' that can be
> used for unit tests, that sort of stuff. Just my tuppence...
> 
> 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