[juddi-Developers] using junit

[Andy Cutright <ac...@borland.com>]

hi steve, et.al.,

i've read the junit 'cookbook'. i want to understand your goals for the 
test suite. do you want to use junit to provide automated testing, and 
standard error reporting? and to provide a common framework / style to 
make the suite easily extensible/ maintained?

i think my few tests can extend junit's TestCase base class. they 
already offer a run() method, in the junit style. junit has some strong 
points. i like the setup()/ teardown() idea. i don't want test cases 
creating artifacts that will affect other classes. being a standards guy 
(CORBA/ J2EE), i like a well documented standard. and the fact that it's 
already -documented- is nice too. my concern is style i suppose: the 
juddi test cases are sufficiently complex that imposing the formal 
structure of setup()/ run()/ shutdown() isn't going to scale, imo.

if we make each test class extend TestCase and implement the run(), 
we'll still be able to use the standard junit error reporting, and the 
junit test harnesses. i'll have some working examples tomorrow afternoon.

thoughts?

cheers,
andy

RE: [juddi-Developers] using junit

[Adam Jack <aj...@TrySybase.com>]

	 my concern is style i suppose: the
	juddi test cases are sufficiently complex that imposing the formal
	structure of setup()/ run()/ shutdown() isn't going to scale, imo.

Perhaps these tests just aren't suited to junit, but that can be
supplemented, or replaced, by N much smaller unit tests.

BTW: There are fancy junit extension for testing things (WWW sites, EJBs)
but I don't know if they have much traction. I see junit tests w/ every
successful product, but I've never seen these others.

Maybe jUDDI needs a "deployment zone" for high level/complex integration
testing. Anybody got a public server to spare?

regards

Adam

Re: [juddi-Developers] using junit

[Andy Cutright <ac...@borland.com>]

hi ya'll,

thanks for the feedback. i wanted to make sure there was no dogmatic 
adherenece to the letter of junit's structure. it sounds to me like 
we're on the same page about using junit.

Adam Jack wrote:

>	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.
>
yeah, i'm aiming at a test plan organized around the API. the structure 
of the classes will fall out of that.

>
>
>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 i play with junit, i'll try to write to its strengths. this is the 
sorta stuff i don't know about junit yet.

i hadn't really thought about testing 'inside' juddi. we could have a 
compliance test suite and an internal test suite (persistence layer, 
etc.), but i would think a compliance suite would exersize all the 
functionality appropriately.

does sourceforge allow us to run our own webserver? it'd be easy enough 
to setup tomcat & test, if that's allowed. we just put it on a 
non-standard port.. i'm not too familiar with the sourceforge process. 
doesn't it provide 'build farms' for the projects? or is it just a CVS/ 
project repository?

cheers,
andy

RE: [juddi-Developers] using junit

[Adam Jack <aj...@TrySybase.com>]

	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

RE: [juddi-Developers] using junit

[Steve Viens <sv...@attbi.com>]

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.

The mock-up of the new jUDDI 1.0 directory structure (juddi.zip) that I
sent out earlier in the week included a dummy jUDDI TestCase under the
src/test directory. The build.xml file in that archive also included a
'test' target that built and ran that test (something to check out - not
sure if anyone noticed).

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.

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

Steve

-----Original Message-----
From: juddi-developers-admin@lists.sourceforge.net
[mailto:juddi-developers-admin@lists.sourceforge.net] On Behalf Of Andy
Cutright
Sent: Thursday, May 29, 2003 7:07 PM
To: juddi-developers@lists.sourceforge.net
Subject: [juddi-Developers] using junit


hi steve, et.al.,

i've read the junit 'cookbook'. i want to understand your goals for the 
test suite. do you want to use junit to provide automated testing, and 
standard error reporting? and to provide a common framework / style to 
make the suite easily extensible/ maintained?

i think my few tests can extend junit's TestCase base class. they 
already offer a run() method, in the junit style. junit has some strong 
points. i like the setup()/ teardown() idea. i don't want test cases 
creating artifacts that will affect other classes. being a standards guy

(CORBA/ J2EE), i like a well documented standard. and the fact that it's

already -documented- is nice too. my concern is style i suppose: the 
juddi test cases are sufficiently complex that imposing the formal 
structure of setup()/ run()/ shutdown() isn't going to scale, imo.

if we make each test class extend TestCase and implement the run(), 
we'll still be able to use the standard junit error reporting, and the 
junit test harnesses. i'll have some working examples tomorrow
afternoon.

thoughts?

cheers,
andy



-------------------------------------------------------
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

RE: [juddi-Developers] using junit

[Adam Jack <aj...@TrySybase.com>]

	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

RE: [juddi-Developers] using junit

[Anou Manavalan <an...@trysybase.com>]

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.

BTW: Eclipse creates the junit tests and testsuite framework for each class
and we can fill in what we need. I see that Steve has got some testdriver in
the main method, we can move them there.

regards,
-Anou

-----Original Message-----
From: juddi-developers-admin@lists.sourceforge.net
[mailto:juddi-developers-admin@lists.sourceforge.net]On Behalf Of Andy
Cutright
Sent: Thursday, May 29, 2003 5:07 PM
To: juddi-developers@lists.sourceforge.net
Subject: [juddi-Developers] using junit


hi steve, et.al.,

i've read the junit 'cookbook'. i want to understand your goals for the
test suite. do you want to use junit to provide automated testing, and
standard error reporting? and to provide a common framework / style to
make the suite easily extensible/ maintained?

i think my few tests can extend junit's TestCase base class. they
already offer a run() method, in the junit style. junit has some strong
points. i like the setup()/ teardown() idea. i don't want test cases
creating artifacts that will affect other classes. being a standards guy
(CORBA/ J2EE), i like a well documented standard. and the fact that it's
already -documented- is nice too. my concern is style i suppose: the
juddi test cases are sufficiently complex that imposing the formal
structure of setup()/ run()/ shutdown() isn't going to scale, imo.

if we make each test class extend TestCase and implement the run(),
we'll still be able to use the standard junit error reporting, and the
junit test harnesses. i'll have some working examples tomorrow afternoon.

thoughts?

cheers,
andy



-------------------------------------------------------
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