Hello,

We are just getting started with jUnit.  One requirement we have is to use
the test system to run load and stress testing, which implies multiple
simultaneous tests being launched.

There is an extension mentioned in the junit.org web pages called
ActiveTestSuite.  The javadoc are sparse to the point of incomprehensibility
for me.

Can anyone point me at some information of how to use this extension?

Thanks in advance,
Bret

Something I do is have a method that loads the property file and
returns a Properties object.  I then pass the Properties object
to the methods that need them.  This really helped as I could
then create the Properties object as I needed in the tests
(with missing properties) and see how my program responded.

Not to mention, it also helped when I changed the load property
method to use the classpath rather than the file system for
loading.  Only had to change code in one place.

John.

----Original Message Follows----
Use ByteArrayInputStream.  It works for me.

"Stevens, Timothy J. (LNG-MBC)" wrote:

  >         Paul,
  >
  >         There isn't really a clean way to get from a Reader to a Stream.
One
  > solution I've used when testing with short input files is using code
within
  > the JUnit test to write the input file to a temporary location on the
file
  > system, then have it automatically deleted when the tests have completed.
  > This way you could easily have your inputstream and would also more
  > accurately represent the way the code will be used in production.
  >
  >         There are plenty of additional sources of info about this out
there
  > on the net. Check out the JUnit Best Practices doc over on JavaWorld.
  >
  >         Hope this helps,
  >
  >         -tim
  >
  > -----Original Message-----
  > From: Paul Michali [mailto:pcm@...]
  > Sent: Tuesday, September 18, 2001 11:05 AM
  > To: junit@yahoogroups.com
  > Subject: [junit] Using strings to test Properties processing?
  >
  > Help! I'm stuck.  My program reads a property file and processes the
  > various properties found. To test this, I have some dummy property
  > files that I use and JUnit tests that read those files and check
  > various things.
  >
  > In an effort to "improve" things, I thought that I could, for testing,
  > use a string as the input stream for the properties and then just
  > use strings in the JUnit tests, insead of having a dozen property files.
  >
  > However, I'm stuck trying to figure out how to do this (warning - Java
  > novice)...
  >
  > The Properties.load() call wants an input stream. For the application,
  > I can create a FileInputStream and pass this to the load() call. For
  > testing, I wanted to use StringBufferInputStream, but that class is
  > deprecated. Instead, they say to use StringReader.
  >
  > How can I convert a StringReader object into a InputStream object so
  > that it can be passed to Properties.load()? Is this possible? If not,
  > are there any other ways to do this, other than using a deprecated
  > class?
  >
  > I'd really like to simplify the tests, as there are many properties
  > that I want to check to make sure they are processed correctly.
  >
  > Thanks in advance!
  >
  >
  > PCM (Paul Michali)
  >
  > Carrier Voice Gateway Business Unit (CVGBU)
  > Cisco Systems, Inc.
  > 250 Apollo Drive
  > Chelmsford, MA 01824
  >
  > Phone : (800) 572-6771 x 45817  (978) 244-5817 [direct]
  > Paging: (800) 365-4578 [voice]  pcm@... [email page]
  >
  > To unsubscribe from this group, send an email to:
  > junit-unsubscribe@yahoogroups.com
  >
  >
  > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
  >
  >
  > To unsubscribe from this group, send an email to:
  > junit-unsubscribe@yahoogroups.com
  >
  >
  > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

--
Disclaimer:  I join all the news groups out of my own interest.  All
opinions expressed here are my
own and not necessarily those of my employer.




_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

-----Original Message-----
From: Pankaj Solanki [mailto:psolanki@...]
Sent: Tuesday, September 18, 2001 1:34 PM
To: junit@yahoogroups.com
Subject: [junit] UML Diagram

Thanks Jason

I meant the UML diagram only.

Regards,

 

Pankaj

 

 

----- Original Message -----

From: Jason Rogers

To: 'junit@yahoogroups.com'

Sent: Monday, September 17, 2001 8:22 PM

Subject: RE: [junit] Rational Rose Model File for JUnit3.7

If by Rational Rose model you simply mean a UML diagram, no.

 

However, there are plenty of programs out there that will take the sources of a software program and create UML from them (including Message sequence diagrams).  Poseidon is one (avaliable at http://www.gentleware.com), and it's free.  It's generally pretty 'good' in the sense that it creates proper diagrams, but it tends to be a little sluggish.  However, since JUnit is not that big, it should do fine.  TogetherJ also touts this capability, but I have never used it.  "Etcetera, etcetera, etcetera..."

 

HTH.

-Jason

-----Original Message-----
From: Pankaj Solanki [mailto:psolanki@...]
Sent: Monday, September 17, 2001 11:24 AM
To: JUnit Yahoo Group
Subject: [junit] Rational Rose Model File for JUnit3.7

Hi All,

 

Will any of you please inform me that is there any Raional Rose Model Files exists for JUnit ?

I am preparing an implementation model for that I requires this information.

 

Thanks,

 

Pankaj

To unsubscribe from this group, send an email to:
junit-unsubscribe@yahoogroups.com


Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

To unsubscribe from this group, send an email to:
junit-unsubscribe@yahoogroups.com


Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

To unsubscribe from this group, send an email to:
junit-unsubscribe@yahoogroups.com


Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

*******************Confidential Notice********************

This e-mail communication may contain information that is

confidential and privileged. The information is intended

to be for the use of the addressee only. If you are not the

named addressee you should not disseminate, distribute or

copy this e-mail: to do so could be a breach of confidence.

Kshema Technologies Ltd.,

# 1, Global Village, Mylasandra,

Mysore Road, Bangalore 560059, INDIA.

Tel: (91)-80-8603600-17

Fax: (91)-80-8603372

**********************************************************

Please consider this example:

I have an interface Foo (or even a base class).   I have a number of
implemetations of Foo (Bar, Jam, Zip).  Now, as it turns out, I can write
FooTest with five different test*() methods, and provided it knows which Foo
Implementation to get, it will pass all 5 tests.   In the interest of OOAO,
I've been solving this problem using inheritance.  I rename FooTest to
FooTestCase, then implement BarTest, JamTest, and ZipTest.  Now, I don't
really like this one too much because I end up with a lot of classes that
who's only difference ought to be parameterized, but it works great.  It has
the virtue that the tests are clearly named, too.

The other way I've considered, is to modify the constructor to take an
additional argument besides the testName.  I don't like this because then
I've got to manually construct TestSuites and possibly name each test
manually. I happen to be a big fan of automation and
suite.add(BarTest.class).

Are there any other suggestions on how to implement a TestMatrix?

Why not a single doTest(Foo implementation) method and five testXxx()
methods that only pass a concrete implementation ?
If you want five TestCases make an abstract parent implementing doTest(...)
and subclass with each a testXxx()... that calls doTest(...)

Mark

-----Original Message-----
From: David Corbin [mailto:dcorbin@...]
Sent: donderdag 20 september 2001 12:12
To: junit@yahoogroups.com
Subject: [junit] Best way to do "Test Matrix"


Please consider this example:

I have an interface Foo (or even a base class).   I have a number of
implemetations of Foo (Bar, Jam, Zip).  Now, as it turns out, I can write
FooTest with five different test*() methods, and provided it knows which Foo
Implementation to get, it will pass all 5 tests.   In the interest of OOAO,
I've been solving this problem using inheritance.  I rename FooTest to
FooTestCase, then implement BarTest, JamTest, and ZipTest.  Now, I don't
really like this one too much because I end up with a lot of classes that
who's only difference ought to be parameterized, but it works great.  It has
the virtue that the tests are clearly named, too.

The other way I've considered, is to modify the constructor to take an
additional argument besides the testName.  I don't like this because then
I've got to manually construct TestSuites and possibly name each test
manually. I happen to be a big fan of automation and
suite.add(BarTest.class).

Are there any other suggestions on how to implement a TestMatrix?



To unsubscribe from this group, send an email to:
junit-unsubscribe@yahoogroups.com


Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

John Goalby wrote:
>
> Something I do is have a method that loads the property file and
> returns a Properties object.  I then pass the Properties object
> to the methods that need them.  This really helped as I could
> then create the Properties object as I needed in the tests
> (with missing properties) and see how my program responded.
>
> Not to mention, it also helped when I changed the load property
> method to use the classpath rather than the file system for
> loading.  Only had to change code in one place.
>

Yes, I just changed my program yesterday to obtain the property file and
create a Properties object and then load. Once that was done, I then
passed
the Properties object to each of the routines I had that parsed the
properties. For testing, I just created a Properties object and then
used
the setProperty() call, as Valdimir suggested.

It works very well. The only thing I saw different was that in a
property
file, I could have a line like "NAME = \tVALUE" and it would process
that
correctly (without the tab), whereas I get a different result, if I do a
setProperty("NAME", "\tVALUE"); so I can't really test those types of
syntactical things. Not a big deal though, as I could have one real
property
file and use that to test those cases, if need be.

I was just surprised that Java didn't have a way to do the equivalent of
StringBufferInputStream for the Properties.load() call (like accepting a
StrngReader). I found it very handy to be able to feed the load either a
FileInputStream or a StringbufferInputStream, as needed.


PCM (Paul Michali)

Carrier Voice Gateway Business Unit (CVGBU)
Cisco Systems, Inc.
250 Apollo Drive
Chelmsford, MA 01824

Phone : (800) 572-6771 x 45817  (978) 244-5817 [direct]
Paging: (800) 365-4578 [voice]  pcm@... [email page]

Does dixie listen on the standard SMTP port? One could just connect and
disconnect to make sure it's running.

On Thu, 13 Sep 2001, Jason Rogers wrote:

> Paul,
>
> I don't recall that dixie has a way of reporting to you that it is running,
> however, it seems likely that you could write an Ant task to look through
> the "innards" of dixie to determine this.
>
> As far as starting dixie, all you need to do is invoke it from Ant using the
> <exec/> or <apply/> on some start-up script (.bat, .sh, etc.) or, since it's
> a Java mail server, use the <java/> task with the fork="yes" attribute.
>
> Example of the Java task:
>
> <target name="isDixieStarted" depends="init">
> [...insert magic here...]
> </target>
>
> <target name="startdixie" depends"isDixieStarted">
>   <java classname="dixiemail.dixie"
>         fork="yes"
>         dir="${directory.in.which.you.want.dixiemail.run}"
>         maxmemory="${maximum.memory.to.allocate.to.new.jvm.for.dixiemail}" >
>     <classpath>
>       <pathelement location="${dixie.jar}"/>
>       <pathelement path="${java.class.path}"/>
>     </classpath>
>   </java>
> </target>
>
> Then run your tests, making the target for testing dependent on
> "startdixie".
>
> HTH.
> -Jason
>
>     > I've made a (simple) build.xml for Ant that builds my application
>     > and runs JUnit for the test part.
>     >
>     > However, when I run my tests, I need to have a mail server (dixie)
>     > running on that machine to ensure that mail messages can
>     > be sent and
>     > received correctly. (Granted, one could debate these are
>     > functional
>     > tests, but that's beside the point).
>     >
>     > Can any one shed any light on how I can A) start up the
>     > mail server
>     > prior to running the test part of the build, and B) how to verify
>     > that the server is still running, when a test is started?
>     >
>     > Once running, I usually leave the mail server running all
>     > the time,
>     > but sometimes I forget to start it and then run my tests and some
>     > of the tests fail. Hence the desire to start the server
>     > and test if
>     > the server is still running as part of the Ant build.
>     >
>     > Later, I'd like to setup CruiseControl (once I figure it
>     > out...) to
>     > do a nightly build and test of the software. I've just started
>     > playing with Ant, CVS, CruiseControl, TomCat, etc. and
>     > there's alot
>     > to absorb, so any suggestions would be very appreciated!
>     >
>     >
>     > PCM (Paul Michali)
>     >
>     > Carrier Voice Gateway Business Unit (CVGBU)
>     > Cisco Systems, Inc.
>     > 250 Apollo Drive
>     > Chelmsford, MA 01824
>     >
>     > Phone : (800) 572-6771 x 45817  (978) 244-5817 [direct]
>     > Paging: (800) 365-4578 [voice]  pcm@... [email page]
>     >
>     > ------------------------ Yahoo! Groups Sponsor
>     > ---------------------~-->
>     > Secure your servers with 128-bit SSL encryption! Grab
>     > your copy of VeriSign's FREE Guide: "Securing Your Web
>     > Site for Business." Get it Now!
>     > http://us.click.yahoo.com/n7RbFC/zhwCAA/yigFAA/NhFolB/TM
>     > ----------------------------------------------------------
>     > -----------~->
>     >
>     > To unsubscribe from this group, send an email to:
>     > junit-unsubscribe@yahoogroups.com
>     >
>     >
>     > Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
>
>
>
>
>
>
> To unsubscribe from this group, send an email to:
> junit-unsubscribe@yahoogroups.com
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>

--
Eric Vought
Chief Technical Officer - QLUE Consulting, Inc.

evought@... toll-free: 888-771-3538  RTP area: 919-816-9901

On 18 Sep, Shane Celis wrote:
> The option I actually went for in my own testing environment was a set of
> duplicate methods called nonFatalAssert, nonFatalFail, and so forth.
> Presenting that though seemed to unduly complicates things.
>

I think this may interest me too. Can you send me the patches?

Thanks,

L

--
Laurent Duperval <mailto:lduperval@...>

Je sens comme un torrent créateur déferler sur la plaine aride de ma
fébrilité.
                                           -Léonard le génie

Bret Waldow wrote:

> Hello,
>
> We are just getting started with jUnit.  One requirement we have is to use
> the test system to run load and stress testing, which implies multiple
> simultaneous tests being launched.
>
> There is an extension mentioned in the junit.org web pages called
> ActiveTestSuite.  The javadoc are sparse to the point of incomprehensibility
> for me.
>
> Can anyone point me at some information of how to use this extension?
>

The ActiveTestSuite runs each test in a separate thread and waits for all the
threads to terminate.

An example usage of setting up an ActiveTestSuite is:

     public static Test suite() {
         TestSuite suite = new ActiveTestSuite();
         suite.addTest(new FirstTest("testSomething"));
         suite.addTest(new TestSuite(SecondTest.class));
         return suite;
     }

Alternatively, you might find JUnitPerf helpful.  It's freely available at:

     http://www.clarkware.com/software/JUnitPerf.html


Mike

--
Mike Clark
Clarkware Consulting, Inc.
Custom Software Architecture, Design,
Development, and Performance Consulting
http://www.clarkware.com

Eric Vought wrote:
>
> Does dixie listen on the standard SMTP port? One could just connect and
> disconnect to make sure it's running.
>

Yes, I just made a custom Ant task yesterday that tries to connect to
Dixie
and fails, if it cannot connect. I'm looking at ways to either set a
property or kick off Dixie from the custom task.

P.S. Since this is very Ant specific thread, I've started presenting
this and
related questions to the Ant mailing list (ant-user@...),
if
case you want to follow this discussion.


PCM (Paul Michali)

Carrier Voice Gateway Business Unit (CVGBU)
Cisco Systems, Inc.
250 Apollo Drive
Chelmsford, MA 01824

Phone : (800) 572-6771 x 45817  (978) 244-5817 [direct]
Paging: (800) 365-4578 [voice]  pcm@... [email page]

Paul Michali wrote:
> I've started presenting
> this and
> related questions to the Ant mailing list (ant-user@...),
> if
> case you want to follow this discussion.

Sorry all. To send to the above list you must subsscribe. You can go to
the Ant home page and subscribe to that list, if interested in Ant
discussions. It is at http://jakarta.apache.org


PCM (Paul Michali)

Carrier Voice Gateway Business Unit (CVGBU)
Cisco Systems, Inc.
250 Apollo Drive
Chelmsford, MA 01824

Phone : (800) 572-6771 x 45817  (978) 244-5817 [direct]
Paging: (800) 365-4578 [voice]  pcm@... [email page]

--- David Corbin <dcorbin@...> wrote:
> Please consider this example:
>
> I have an interface Foo (or even a base class).   I have a number of
> implemetations of Foo (Bar, Jam, Zip).  Now, as it turns out, I can
> write FooTest with five different test*() methods, and provided it

We've had good, maintainable results doing this.

The "knows which class to construct" we solve with a Template Method:

class FooTestCase extends TestCase {
   // ...
   abstract public Foo createFoo(); // Add some arguments if needed


   public void testXyZzy() {
     final Foo fooUnderTest = createFoo();
     // ...
   }
}

Regards,

Rob


__________________________________________________
Terrorist Attacks on U.S. - How can you help?
Donate cash, emergency relief information
http://dailynews.yahoo.com/fc/US/Emergency_Information/

You may want to check out the com.qlue.util.getopt package
(http://qcijutils.qlue.com). The GetOpt package contains an object
oriented mechanism for parsing arbitrarily complex types out of
command-line options. It can and has also been applied to strings in
properties files.  Its main advantage is that it factors out and packages
common parsing operations and syntax checking as well as putting all of
the error checking up front so that your application can just assume that
the runtime configuration is valid. The individual option type classes
(integers, flags, strings, lists, etc) can be tested in isolation and
testing the application classes is correspondingly simplified.

Feel free to use the framework if it appeals, or simply use it as an
example. Also feel free to ask me questions about the design, intent, or
future directions of the package.


On Tue, 18 Sep 2001, Paul Michali wrote:

> Vladimir Bossicard wrote:
> >
> > >
> > >
> > >In an effort to "improve" things, I thought that I could, for testing,
> > >use a string as the input stream for the properties and then just
> > >use strings in the JUnit tests, insead of having a dozen property files.
> > >
> > The question is: what do you want to test?
> > 1) the loading of the properties files?
> > 2) the processing of the properties?
> >
> > >I'd really like to simplify the tests, as there are many properties
> > >that I want to check to make sure they are processed correctly.
>
> I have properties like these:
>
> skip.empty.msgs = SLOW, DELAY
>
> filter1.1 = some text to filter out for path #1
> filter1.2 = another filter on path 1
> filter2.1 = a filter for another path
>
> In the first property, I'm parsing out the strings (SLOW and DELAY). In
> the
> rest of the properties, I'm looking first to see if they exist and then
> I'm
> collecting all the entries for each path and putting them into a List of
> String. There are others, but this is the gist of what I'm dealing with.
>
>
> > >
> > I think the answer is 2...  What I would do is simply create a Propertie
> > object and fill it with values.  You will easily test your methods
> > without having dozen of files everywhere.
>
> Interesting idea. You're saying to create a Properties object and then
> "set" the values as I want and to then process them. That would do some
> of the testing. However, I also need to make sure some mandatory
> Properties
> are there and have values assigned as well.
>
>
> PCM (Paul Michali)
>
> Carrier Voice Gateway Business Unit (CVGBU)
> Cisco Systems, Inc.
> 250 Apollo Drive
> Chelmsford, MA 01824
>
> Phone : (800) 572-6771 x 45817  (978) 244-5817 [direct]
> Paging: (800) 365-4578 [voice]  pcm@... [email page]
>
> To unsubscribe from this group, send an email to:
> junit-unsubscribe@yahoogroups.com
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>

--
Eric Vought
Chief Technical Officer - QLUE Consulting, Inc.

evought@... toll-free: 888-771-3538  RTP area: 919-816-9901

We've used the same basic template to good effect.

On Thu, 20 Sep 2001, Robert Sartin wrote:

>
> --- David Corbin <dcorbin@...> wrote:
> > Please consider this example:
> >
> > I have an interface Foo (or even a base class).   I have a number of
> > implemetations of Foo (Bar, Jam, Zip).  Now, as it turns out, I can
> > write FooTest with five different test*() methods, and provided it
>
> We've had good, maintainable results doing this.
>
> The "knows which class to construct" we solve with a Template Method:
>
> class FooTestCase extends TestCase {
>   // ...
>   abstract public Foo createFoo(); // Add some arguments if needed
>
>
>   public void testXyZzy() {
>     final Foo fooUnderTest = createFoo();
>     // ...
>   }
> }
>
> Regards,
>
> Rob
>
>
> __________________________________________________
> Terrorist Attacks on U.S. - How can you help?
> Donate cash, emergency relief information
> http://dailynews.yahoo.com/fc/US/Emergency_Information/
>
> To unsubscribe from this group, send an email to:
> junit-unsubscribe@yahoogroups.com
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>

--
Eric Vought
Chief Technical Officer - QLUE Consulting, Inc.

evought@... toll-free: 888-771-3538  RTP area: 919-816-9901

--- gopala krishnan T <talluri_krishnan@...>
wrote:
> hi
> i dont know about the junitee.but presently we are
> using super150 -a EJB testing tool which is working
> quite fine.
> if u are using weblogic 5.1 then u can as well go
> for EJBVerify-an another testing tool
>   ----- Original Message -----
>   From: Kaarle Kaila
>   To: junit@yahoogroups.com
>   Sent: Wednesday, September 19, 2001 5:28 PM
>   Subject: [junit] Testing J2EE applications
>
>
>I have been looking into ways of testing J2EE
>applications with JUnit. Part of my application are
>straight methods that I can test locally but other
>parts requires the J2EE environment to be active
>(weblogic in this case).
...........

I could find EJBVerify. It does not look like a JUnit
tool. What is super150. The search engine finds a lot
but no testing tool?

Kaarle Kaila


__________________________________________________
Terrorist Attacks on U.S. - How can you help?
Donate cash, emergency relief information
http://dailynews.yahoo.com/fc/US/Emergency_Information/

--- In junit@y..., Paul Michali <pcm@c...> wrote:
> Help! I'm stuck.  My program reads a property file and processes the
> various properties found. To test this, I have some dummy property
> files that I use and JUnit tests that read those files and check
> various things.
>
> In an effort to "improve" things, I thought that I could, for
testing,
> use a string as the input stream for the properties and then just
> use strings in the JUnit tests, insead of having a dozen property
files.
[...]

Hm. Your program reads a property file. Why? Can it just take a
Properties object instead? Can something else read the Properties
from file and pass it in to your program?

You probably don't need to test Properties.load(), so concentrate on
testing your own code. Just give that class a Properties object and
be done with it.

JBR.

http://c2.com/cgi/wiki?AbstractTestCases

Enjoy.

JBR
--- In junit@y..., "David Corbin" <dcorbin@m...> wrote:
> Please consider this example:
>
> I have an interface Foo (or even a base class).   I have a number of
> implemetations of Foo (Bar, Jam, Zip).  Now, as it turns out, I can
write
> FooTest with five different test*() methods, and provided it knows
which Foo
> Implementation to get, it will pass all 5 tests.   In the interest
of OOAO,
> I've been solving this problem using inheritance. [...]

Yes!!!!!!!! You can do it too!!!!!! Just try a couple of web
searches, then when you have specific questions, come back and ask
them!!!!!!

JBR.

--- In junit@y..., "Walfredo Cirne" <walfredo@d...> wrote:
> Hi All!!!
>
> Any ideas on how to write tests for multithreaded code?
>
> []s
> Walfredo

Hi,

   You can use assertTrue() to replace assert() method in your unit tests.  I
did it in Junit3.7 version and it worked fine. Hope this helpes!

qionghua yang

>From: "Starkie, Michael" <MStarkie@...>
>Reply-To: junit@yahoogroups.com
>To: <junit@yahoogroups.com>
>Subject: [junit] assert and Java 1.4
>Date: Wed, 19 Sep 2001 09:53:12 -0400
>
>In Java 1.4 "assert" is a keyword and may not be used as an identifier,
>therefore my regression test code fails to build when using java 1.4.
>What is Junit going to do about it?
>
>thanks,
>
>mike


_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

I took Vladimir's advice and pass a Properties object to each method
that needs to process the properties, rather than have these methods
access a Properties data member (that is previously loaded from a
stream.

Now, in the application, I get the filename from the command line, open
a
FileInputStream, create a Properties object, and load it with the
stream.
That properties object is passed to the methods that process the
properties.

In the JUnit test, I create a Properties object, and then use the
setProperty("name", "value") call to set the properties I need, prior
to passing this object to the methods that do the processing.

The only limitation I see with this method is that I cannot verify
property file entries like "name = \tvalue", but I guess that would be
testing the operation of the load() call and is not really necessary.


Thanks everyone, for the suggestions. This is working great now, I've
improved my testing coverage, and I got some refactoring experience.


PCM (Paul Michali)

Carrier Voice Gateway Business Unit (CVGBU)
Cisco Systems, Inc.
250 Apollo Drive
Chelmsford, MA 01824

Phone : (800) 572-6771 x 45817  (978) 244-5817 [direct]
Paging: (800) 365-4578 [voice]  pcm@... [email page]

I created a new patch that allows you to change the assert behavior,
between the standard "fatal" assertions, and the new non-standard
"non-fatal" assertions. Fatal assertions imply only one failure per
test, whereas the non-fatal assertions allow for multiple failures per
test. This behavior can be manipulated via an accessor on the Assert
class (see example on website). By default it is initialized to the
standard fatal assertions.

webpage: http://www.gnufoo.org/junit/index.html#releases
patch: http://www.gnufoo.org/junit/junit3.7b.patch
jar (includes source): http://www.gnufoo.org/junit/junit3.7b.jar

-shane


On Thursday, September 20, 2001, at 07:17  AM, Laurent Duperval wrote:

> On 18 Sep, Shane Celis wrote:
>> The option I actually went for in my own testing environment was a set
>> of
>> duplicate methods called nonFatalAssert, nonFatalFail, and so forth.
>> Presenting that though seemed to unduly complicates things.
>>
>
> I think this may interest me too. Can you send me the patches?
>
> Thanks,
>
> L

err... http://www.gnufoo.org/junit/index.html#failures

-----Original Message-----
From: Shane Celis [mailto:shane@...]
Sent: Friday, September 21, 2001 4:18 PM
To: junit@yahoogroups.com
Subject: Re: [junit] Proper use of TestReult


I created a new patch that allows you to change the assert behavior,
between the standard "fatal" assertions, and the new non-standard
"non-fatal" assertions. Fatal assertions imply only one failure per
test, whereas the non-fatal assertions allow for multiple failures per
test. This behavior can be manipulated via an accessor on the Assert
class (see example on website). By default it is initialized to the
standard fatal assertions.

webpage: http://www.gnufoo.org/junit/index.html#releases
patch: http://www.gnufoo.org/junit/junit3.7b.patch
jar (includes source): http://www.gnufoo.org/junit/junit3.7b.jar

-shane


On Thursday, September 20, 2001, at 07:17  AM, Laurent Duperval wrote:

> On 18 Sep, Shane Celis wrote:
>> The option I actually went for in my own testing environment was a set
>> of
>> duplicate methods called nonFatalAssert, nonFatalFail, and so forth.
>> Presenting that though seemed to unduly complicates things.
>>
>
> I think this may interest me too. Can you send me the patches?
>
> Thanks,
>
> L


To unsubscribe from this group, send an email to:
junit-unsubscribe@yahoogroups.com


Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

--- Neil Swingler <nswingler@...> wrote:
> I always compare arrays like this:
>
> assertEquals( Arrays.asList(array1),
> Arrays.asList(array2) );
>
> Not very helpful diagnostics if the array length is
> long but it is simple.
>
> --
> Neil Swingler
>
> > -----Original Message-----
> > From: J. B. Rainsberger
> [mailto:jbrains762@...]
> > Sent: 27 July 2001 17:47
> > To: junit@yahoogroups.com
> > Subject: [junit] assertEquals(array1, array2)
> >
> >
> > >In this example you may want to write a custom
> assert().  You don't
> > >give the types of the arrays nor their expected
> lengths (do they hold
> > >a few simple elements, dozens of complicated
> ones, millions, ...).
> > >Perhaps you'd be better off constructing a vector
> of differences and
> > >asserting the vector as empty.  Adding the
> differences to a string
> > >and asserting it as equal to "".  Or counting the
> differences and
> > >assertEquals(0, count).
> >
> > Wow! This is an awesome idea. Let's see if we can
> take this
> > further. Here is
> > code off the top of my head.
> >
> > public class ArrayDifference {
> >     public Object expected;
> >     public Object actual;
> >     public ArrayDifference(Object anExpected,
> Object anActual) {
> >         expected = anExpected;
> >         actual = anActual;
> >     }
> >     public String toString() {
> >         return ("Expected <" + expected + "> but
> got <" + actual + ">";
> >     }
> > }
> >
> > public void assertEqualArrays(Object[] expected,
> Object[] actual) {
> >     assertNotNull("expected is null", expected);
> >     assertNotNull("actual is null", actual);
> >     assertEquals(expected.length, actual.length);
> >     final List differences = new ArrayList();
> >     for (int i = 0; i < expected.length; i++) {
> >         if (expected[i] == null
> >             || !(expected[i].equals(actual[i]))) {
> >             differences.add(new
> ArrayDifference(expected[i], actual[i]));
> >         }
> >     }
> >     assertEquals(new ArrayList(), differences);
> > }
> >
> > This builds up a list of differences. The list
> knows how to
> > present itself
> > as a string (List does that). Each difference
> presents itself as a string
> > (ArrayDifference does that). If you need prettier
> output, create a class
> > that wraps a List of ArrayDifferences and makes
> the output prettier.
> >
> > I like the sound of this technique. I think I'll
> put this up as a best
> > practice until someone else tells me something
> wrong with it.
> >
> > JBR.
> >
> >
> >
>
_________________________________________________________________
> > Get your FREE download of MSN Explorer at
> http://explorer.msn.com/intl.asp
> >
> >
> >
> > To unsubscribe from this group, send an email to:
> > junit-unsubscribe@yahoogroups.com
> >
> >
> > Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
> >
> >
>
>


__________________________________________________
Do You Yahoo!?
Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger.
http://im.yahoo.com

Hi
in order to convince management at my company that writing automatic
unit tests is not only cheaper for code maintenance but speeds up the
development effort at -all- project phases, I would appreciate your
feedback on the following questions:

- what percentage of time do you spend writing application code, and
writing unit tests?

- what percentage of time do you spend bug fixing and debugging?

- if unit testing was introduced in your company while you were
there, please tell me something about the effects on delivery time?

And more such infos would be greatly appreciated.

Thanks,

Heikki Doeleman
heikki@...

Hi,

I am also a little unsure of how to test multithreaded code, and I hope my
question is a bit more specific than the last one :-)

I wrote this test case to test my multithreaded code, and it appears to work
on my platform. (Windows NT, jdk 1.2.2) I am just worried that it only
passes because the thread scheduling of the JVM implementation I am using
happens to work out right. Has anyone else tried to write this kind of test?
What might be a better approach?

Thanks!

Emily

----- code in question -------------------

public class LockManagerTest extends TestCase {
     private LockManager lockManager = new LockManager();

     /**
      * test for the requirement that the obtainLock method on
      * LockManager must block until the requested lock becomes
      * available
      */
     public void testBlocks() {
         final int recordNo = 1;
         Runnable getsLockFirst = new GetAndHoldLockFor100(recordNo);
         Runnable getsLockAfterwards = new Runnable() {
             public void run() {
                 // assert the record is locked when we first ask, but
becomes
                 // available (or else the whole test run hangs).
                 assert(lockManager.isRecordLocked(recordNo));
                 int key = lockManager.obtainLock(recordNo);
             }
         };
         Thread one = new Thread(getsLockFirst);
         Thread two = new Thread(getsLockAfterwards);
         one.start();
         two.start();
         // wait for test to run before returning
         try {
             Thread.currentThread().sleep(300);
         } catch (InterruptedException e) {}

     }

     private class GetAndHoldLockFor100 implements Runnable {
         private int recordNo;
         public GetAndHoldLockFor100(int recordNo) {
             this.recordNo = recordNo;
         }
         public void run() {
                 int recordKey = lockManager.obtainLock(recordNo);
                 try {
                     Thread.currentThread().sleep(100);
                 } catch (InterruptedException e) {}
                 lockManager.releaseLock(recordNo, recordKey);
             }
     }
}

------ end code in question ---------------------------------

Well, some points:

1) I don't see where you release the lock in the getsLockAfterwards
thread. This can cause your test to fail if you have more than one
testcase in that test class.

2) Along similar lines, you should initialize your LockManager in setUp()
to ensure that it is recreated before each test. That way, if a test fails
and leaves the LockManager in a bad state, you other tests will still
probably run.

3) I think you can make it a bit more robust like so:

      public void testBlocks() {
          final int recordNo = 1;
	  final Object syncObject = new Object();
          Runnable getsLockFirst = new Runnable() {
              public void run() {
		  synchronized (syncObject) {
                      int recordKey = lockManager.obtainLock(recordNo);
		      syncObject.notify();
                      try {
		          wait(syncObject);
                      } catch (InterruptedException e) {}
                      lockManager.releaseLock(recordNo, recordKey);
                  }
              } // run()
          }; // Runnable

          Thread getLockThread = new Thread(getsLockFirst);

	  synchronized (syncObject)
	  {
         	 getLockThread.start();
		 try {
	 	     wait(syncObject);
		 } catch InterruptedException(e) {}

                 assert(lockManager.isRecordLocked(recordNo));
	         syncObject.notify();
          }

          // wait for thread to finish before returning
          try {
              getLockThread.join(300);
          } catch (InterruptedException e) {}

	  // If it is stuck, unstuck it
	  If (getLockThread.isAlive())
	  {
	      getLockThread.interrupt();
	      fail("Thread never released lock.");
	  } else {
	     assert(!(lockManager.isRecordLocked(recordNo)));
          }
     }

I haven't compiled or run this, and it may not be perfect, but there are
several things to note:

1) There's only one extra thread to worry about.

2) You have several control points where you know your thread and the
testcase code are in sync. Your first assert won't be run until the record
lock has been obtained and your thread waits to make sure the testcode has
had a chance to verify that fact. The test method already has a lock on
the synchronization object before the subordinate thread even starts
executing, so there can be no issue of timing no matter what the platform
does. The wait() statements release their lock and queue themselves for
notification atomically, providing a smooth transfer of control with no
possible timing issues. The test code is bludgeoned into behaving in a
predictable, linear manner.

3) A join() with a timeout replaces the sleep. This will wait for your
child thread to die before returning, but, if things appear stuck, you get
the option of interrupting the thread. Unlike sleep(), join() will return
as quickly as it can.

4) Since there are no sleeps anywhere here, your test code should execute
as quickly as possible. Otherwise, as you add testcases, the arbitrary
lengths of time will begin adding up and you will be tempted to not run
the regression tests as often as you should.

Testing threaded code like this is always a royal pain because you
spend at least as much time debugging your test code as the code under
test. In this case, you are testing a very simple feature, but the test
code is fairly complex.

In general, though, you should put a lot of effort into factoring out all
of your thread synchronization code into centralized, independently
tested, reusable code and/or depend on library routines wherever you can.
Keep as much of your application as linear as possible so you have to
write as few of these testcases as possible.

On Mon, 24 Sep 2001, Emily Bache wrote:

> I am also a little unsure of how to test multithreaded code, and I hope my
> question is a bit more specific than the last one :-)
>
> I wrote this test case to test my multithreaded code, and it appears to work
> on my platform. (Windows NT, jdk 1.2.2) I am just worried that it only
> passes because the thread scheduling of the JVM implementation I am using
> happens to work out right. Has anyone else tried to write this kind of test?
> What might be a better approach?
>
> Thanks!
>
> Emily
>
> ----- code in question -------------------
>
> public class LockManagerTest extends TestCase {
>     private LockManager lockManager = new LockManager();
>
>     /**
>      * test for the requirement that the obtainLock method on
>      * LockManager must block until the requested lock becomes
>      * available
>      */
>     public void testBlocks() {
>         final int recordNo = 1;
>         Runnable getsLockFirst = new GetAndHoldLockFor100(recordNo);
>         Runnable getsLockAfterwards = new Runnable() {
>             public void run() {
>                 // assert the record is locked when we first ask, but
> becomes
>                 // available (or else the whole test run hangs).
>                 assert(lockManager.isRecordLocked(recordNo));
>                 int key = lockManager.obtainLock(recordNo);
>             }
>         };
>         Thread one = new Thread(getsLockFirst);
>         Thread two = new Thread(getsLockAfterwards);
>         one.start();
>         two.start();
>         // wait for test to run before returning
>         try {
>             Thread.currentThread().sleep(300);
>         } catch (InterruptedException e) {}
>
>     }
>
>     private class GetAndHoldLockFor100 implements Runnable {
>         private int recordNo;
>         public GetAndHoldLockFor100(int recordNo) {
>             this.recordNo = recordNo;
>         }
>         public void run() {
>                 int recordKey = lockManager.obtainLock(recordNo);
>                 try {
>                     Thread.currentThread().sleep(100);
>                 } catch (InterruptedException e) {}
>                 lockManager.releaseLock(recordNo, recordKey);
>             }
>     }
> }
>
> ------ end code in question ---------------------------------
>
>
> To unsubscribe from this group, send an email to:
> junit-unsubscribe@yahoogroups.com
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>

--
Eric Vought
Chief Technical Officer - QLUE Consulting, Inc.

evought@... toll-free: 888-771-3538  RTP area: 919-816-9901

What about we do a poll in yahoo group.  I am always curious in the answer.  I
am all infected by JUnit now but whenever I talk
with people who has never used JUnit, I don't find my argument that convincing
except 'You have to see it to believe it', which,
sort of sucks.

--
Disclaimer:  I join all the news groups out of my own interest.  All opinions
expressed here are my own and not necessarily
those of my employer.



Heikki wrote:

> Hi
> in order to convince management at my company that writing automatic
> unit tests is not only cheaper for code maintenance but speeds up the
> development effort at -all- project phases, I would appreciate your
> feedback on the following questions:
>
> - what percentage of time do you spend writing application code, and
> writing unit tests?
>
> - what percentage of time do you spend bug fixing and debugging?
>
> - if unit testing was introduced in your company while you were
> there, please tell me something about the effects on delivery time?
>
> And more such infos would be greatly appreciated.
>
> Thanks,
>
> Heikki Doeleman
> heikki@...
>
>
> To unsubscribe from this group, send an email to:
> junit-unsubscribe@yahoogroups.com
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

Here's something I've been working on. It's a paper that talks about some
techniques for developing a database application test-first. The example code is
in the cvs respository on sourceforge, accessible via
http://www.mockobjects.com.

  http://www.mockobjects.com/papers/jdbc_testfirst.html

Comments, etc?

Steve

> I am also a little unsure of how to test multithreaded code, and I hope my
> question is a bit more specific than the last one :-)

Much more specific, Emily. Thank you. It's unfortunate that I'm still a
multithreading moron, otherwise I'd try to answer your question. Anyone
else?!

JBR.