[juddi-Developers] first pass at some tests, comments please

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

i'm attaching a jar. the tests run under junit. comments if you please,

cheers,
andy

RE: [juddi-Developers] first pass at some tests, comments please

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

	>
	>5) Try to pass a message to the assertions, 'cos that message shows up in
	>errors/logs & helps.
	>
	>	testNotNull("Got an answer", answer);
	>
	i'll take a look at this. i really don't like verbose error logs. when
	you have to look at a lot of output, it's hard to find the important
	bits. if the some test
	fails, let an engineer run the test & figure out what's wrong.. but i'm
	not a zealot...

A few characters is hardly verbose. ;-)
If you have more than one assertion in a test method (and you ought) you can
use the line number to distinguish, but a tag is better. Use "1", "2", "3"
if you feel so inclined, but I think human readable is better. :-0

	>
	>6) Your configurator --- do you need JSSE to work on the command line?
	>
	probably. is that an issue? i'm not terribly familiar with that stuff.

No clue, I guess we'll find out...

	>... individual assertions save time when a bugs occurs. If a null pointer
	>occurs, one knows exactly where & isn't guessing on a long line of
possible
	>offenders.
	>
	yeah, sloppy coding. normally i'm pretty religious about checking the
	return code, or verifying a ptr before accessing it.

Test's can be sloppy, crashing is detected & reported just as much as an
assertion failure. That said, I like readable error -- and when they added
assertNotNull recently I've added it a lot.

	>
	>and finally -- spanking just isn't PC these days. ;-)
	>
	liked that huh? you're an attentive reviewer.. that's good :)

Not so attentive I spotted you were from Borland. Sorry about the E!@#!@#!@#
IDE thing. :)

Adam

Re: [juddi-Developers] first pass at some tests, comments please

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

comments inlined

Adam Jack wrote:

>Andy,
>
>A good start. Comments...
>
>1) Do you use eclipse or ant? [Code doesn't look like you use eclipse]. I
>believe they look for *Test.class not Test*.class. [Maybe somebody w/ juddi
>in eclipse can try this.]
>
jbuilder 9, of course :) i'll make this stuff ant based though. i used 
the jbuilder automated stuff just to get a handle on how junit works.

>4) I usually add these to my test classes. I think they are valuable, the
>second is mainly for quick manual tests. I can't recall what the constructor
>does, but think it helps w/ some runners.
>
>    public CollectorTests(String arg0) {
>        super(arg0);
>    }
>
>    public static void main(String[] args) {
>        junit.textui.TestRunner.run(CollectorTests.class);
>
yeah, i was running under the jbuilder framework. it invokes the 
textui.TestRunner directly. antification will draw out these little 
problems.

>    }
>
>5) Try to pass a message to the assertions, 'cos that message shows up in
>errors/logs & helps.
>
>	testNotNull("Got an answer", answer);
>
i'll take a look at this. i really don't like verbose error logs. when 
you have to look at a lot of output, it's hard to find the important 
bits. if the some test
fails, let an engineer run the test & figure out what's wrong.. but i'm 
not a zealot...

>
>6) Your configurator --- do you need JSSE to work on the command line?
>
probably. is that an issue? i'm not terribly familiar with that stuff. 
the underlying client library is UDDI4J, which by default is interested 
in that library. i honestly haven't bothered to figure out why.

>
>7) In TestFindBusiness you call :
>
>
>and you have code like:
>
>  if (businessList.getBusinessInfos().getBusinessInfoVector().size() != 1) {
>    return false;
>  }
>... individual assertions save time when a bugs occurs. If a null pointer
>occurs, one knows exactly where & isn't guessing on a long line of possible
>offenders.
>
yeah, sloppy coding. normally i'm pretty religious about checking the 
return code, or verifying a ptr before accessing it.

>
>9) Is the one time "init" in UDDITestBase.java safe? Are you sure that later
>tests aren't affected by a "tainted" set of objects? Slower, but safer,
>would be setUp() re-initialising...
>
yeah, i'm fairly certain there's no issue with that. at some point, 
tests will be written for the authorization token stuff, and that will 
be an issue.

>
>and finally -- spanking just isn't PC these days. ;-)
>
liked that huh? you're an attentive reviewer.. that's good :)

cheers,
andy

RE: [juddi-Developers] first pass at some tests, comments please

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

Andy,

A good start. Comments...

1) Do you use eclipse or ant? [Code doesn't look like you use eclipse]. I
believe they look for *Test.class not Test*.class. [Maybe somebody w/ juddi
in eclipse can try this.]
2) Putting things in org.juddi.test is fine, but (and this is a repeat) you
might wish to use the same package as the classes you are testing. It seems
odd to have the same package in a separate tree, but it works. Since these
classes don't ship, and don't get into javadocs, there is no harm.
3) Have you tried these under ant? I don't know if junit sets the $CWD so as
the pick up the samples.prop
4) I usually add these to my test classes. I think they are valuable, the
second is mainly for quick manual tests. I can't recall what the constructor
does, but think it helps w/ some runners.

    public CollectorTests(String arg0) {
        super(arg0);
    }

    public static void main(String[] args) {
        junit.textui.TestRunner.run(CollectorTests.class);
    }

5) Try to pass a message to the assertions, 'cos that message shows up in
errors/logs & helps.

	testNotNull("Got an answer", answer);

6) Your configurator --- do you need JSSE to work on the command line?

7) In TestFindBusiness you call :

	protected boolean queryCaseSensitiveMatch()

and you have code like:

  if (businessList.getBusinessInfos().getBusinessInfoVector().size() != 1) {
    return false;
  }

This might be nicer as an assertion (or set) w/ a unique message:

	assertNotNull("Received a business List", businesList);
	assertNotNull("Received a business Info", businessList.getBusinessInfos());
	...
	assertEqual("Received a single entry", ...size(), 1);

... individual assertions save time when a bugs occurs. If a null pointer
occurs, one knows exactly where & isn't guessing on a long line of possible
offenders.

8) Don't catch exceptions and fail w/ a message, you lose the helpful stack:

	  }
  catch (TransportException ex) {
    fail(ex.toString());
  }

.. just set your test methods (and helper protected methods) as throws
Exception, and let it. The TestRunner will catch/display/log for you. In
ecliplse one can click on the stack trace to get to the code...

9) Is the one time "init" in UDDITestBase.java safe? Are you sure that later
tests aren't affected by a "tainted" set of objects? Slower, but safer,
would be setUp() re-initialising...

and finally -- spanking just isn't PC these days. ;-)

regards,

Adam

PS. yes -- I am test infected, unit tests save time in the long run &
dramatically increase quality.
-----Original Message-----
From: juddi-developers-admin@lists.sourceforge.net
[mailto:juddi-developers-admin@lists.sourceforge.net]On Behalf Of Andy
Cutright
Sent: Friday, May 30, 2003 1:46 PM
To: juddi-developers@lists.sourceforge.net
Subject: [juddi-Developers] first pass at some tests, comments please


i'm attaching a jar. the tests run under junit. comments if you please,

cheers,
andy