Hi Johannes,

Thanks for taking the time to share some classes to help me. I downloaded
your jar and I had a look. The class utmj.tests.AllTests doesn't compile, so
I removed it. Unfortunately not all the other tests pass. Although all the
utmj.threaded.AllTests tests pass, the utmj.threaded.example.AllTests don't
all pass:

.............F.F..F.F..F.F..F.F..F.F..F.F..F.F..F.F..F.F..F.
F..F.F..F.F...F..F.F..F.F..F.F..F.F..F.F..F.F..F.F.

Time: 20.229 There were 39 failures:

1)
testTenPutThreadsVersusOneTakeThread(utmj.threaded.example.NonDeterministicB
oundedBufferTest)junit.framework.AssertionFailedError: Buffer is empty
expected:<0> but was:<1>
<snipped for brevity>

FAILURES!!! Tests run: 72,  Failures: 39,  Errors: 0

(run with JUnit 3.7 on Windows NT, java 1.3)

I'm hesitant to look more closely into your code when the tests bundled with
it don't run.

Regards,

Emily

>
> Sorry for not answering your particular questions on the topic and not
> referring to your example.
>
> What I want to provide is some code I have had in my drawer for some
> time. It basically consists of a few utility classes for testing in a
> multithreaded environment:
> - ThreadedTest: A decorator for running a test in a thread of its own.
> (More or less stolen from JUnitPerf)
> - MultiThreadedTest: A decorator which catches exceptions and test
> failures in spawned threads and makes the testcase fail.
> - ExceptionAssert: A helper class to test for expected exceptions in
> spawned threads.
> - RetriedAssert: A helper class to test for an assert
> condition up to a
> given time limit. (also stolen)
> - ConcurrentTestCase: A subclass of TestCase which provides
> some help in
> doing the kind of semi-deterministic testing which you want to do in
> your example. An example for using this class is also provided in a
> subpackage *.example. Therein you find a test suite for the
> BoundedBuffer example discussed in
> http://c2.com/cgi/wiki?JavaUnitTestChallangeSolved.
>
> I just uploaded the code to the group's files area:
> threadedtesting.jar
>
> Comments appreciated.
>
> Johannes
>
>

Emily,

Thanks for looking at the code.

> The class utmj.tests.AllTests doesn't compile, so
> I removed it.

This class shouldn't be there in the first place. It's completely out of
context. My mistake.

> Unfortunately not all the other tests pass. Although all the
> utmj.threaded.AllTests tests pass,

This is the main thing, so you should be able to use the package.

> the utmj.threaded.example.AllTests don't
> all pass:
[...]
> I'm hesitant to look more closely into your code when the tests bundled with
> it don't run.

This is expected behaviour, since the example test suite is there to
show two little synchronisation errors in the BoundedBuffer class. Look
at the class' source and change the two lines which are marked as
containing the errors (notifyAll() should replace notify()). THEN, all
tests should run succesfully.

regards, Johannes

--- In junit@y..., Berin Loritsch <bloritsch@a...> wrote:
> I have been using JUnit 3.7 for a couple of months now, and
> have run accross something very frustrating.  We (the Apache
> Avalon project) use Ant to do our builds and automated testing,
> however the behavior for test collection is different based
> on wether a Test is a TestCase or a TestSuite.
>
> Your FAQ suggests that for one-time setup code you need to run
> it in a TestSuite.

This is what TestSetup is for. Wrap the suite in a subclass of
TestSetup, override setUp() (and maybe tearDown()) in your subclass,
and it only gets run once.

Alternatively, you could consider how to untangle your design so you
didn't need one-time setup.

Kent

John Mammen wrote:

> --- In junit@y..., Vitezslav Stejskal <vitezslav.stejskal@c...> wrote:
> > Hi John,
> >
> > did you apply the FFJ 2.0 Templates Patch from
> > http://junit.netbeans.org/JUnit_installation.html ?
>
> Hello Vita,
>
> Yes, I did. I downloaded the zip and created Junit directory under
> the templates and copied two files, SimpleTest.java and
> filesystem.atttributes.
>
> Thats the patch you are talking about, I think.
>

Hmm, yes it is. Do you see SimpleTest template in popup menu
or New Wizard (right-click some folder in filesystems tab and choose
New; or go in main menu File | New). Your template should be listed there,
please check also letters capitalization.

Vita

>
> Thanks
> John
>
> >
> > Vita
> >
> > John Mammen wrote:
> >
> > > Hello Group,
> > >
> > > I have installed junit on forte using .nbm file and I have mounted
> > > the junit.jar file. On the tools menu I get create,run and open
> menu.
> > > But in the create menu, I am not getting the template for test and
> > > suit class drop downs are empty.
> > > I have already setup the templates in the templates directory and
> > > also set up the executor.
> > >
> > > But how do I get the create dialog box to use the template.
> > > Any help is appreciated. I am using Forte IE 2.0 build 1160
> > >
> > > Thanks
> > > John
> > >
> > >
> > > To unsubscribe from this group, send an email to:
> > > junit-unsubscribe@y...
> > >
> > >
> > > Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
> >
> > --
> > Vitezslav Stejskal, Software engineer
> >
> > SUN Microsystems Czech s.r.o.
> > e-mail: vitezslav.stejskal@c...
> > tel:    +420 2 3300-9232
>
>
> 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/

--
Vitezslav Stejskal, Software engineer

SUN Microsystems Czech s.r.o.
e-mail: vitezslav.stejskal@...
tel:    +420 2 3300-9232

I found on http://sourceforge.net/projects/junitee
software that let's me test EJB's and other Java
classes that run under J2EE such as weblogic 5.1.

I made some patches to the software and have tried to
contact the author but with no response. I wonder why
there is nothing about this software on any forums
that I have found.

I like it. It is easy to use too. Has it been overrun
by something else (like Cactus maybe??)

Kaarle Kaila

__________________________________________________
Do You Yahoo!?
Listen to your Yahoo! Mail messages from any phone.
http://phone.yahoo.com

----- Original Message -----
From: "Kaarle Kaila" <kaakaila@...>
To: <junit@yahoogroups.com>
Sent: Tuesday, October 02, 2001 10:19 AM
Subject: [junit] Testing with JUnitEE


> I found on http://sourceforge.net/projects/junitee
> software that let's me test EJB's and other Java
> classes that run under J2EE such as weblogic 5.1.
>
> I made some patches to the software and have tried to
> contact the author but with no response.

I've also tried to contact Jeff, but both his email at infohazard and at
sourceforge seem to be no longer valid. If you find his email could you
please forward it to me too ? FYI, I work on the Cactus project and wanted
to aski Jeff if we would like to join force with the Cactus team and help us
there ... :-)

> I wonder why
> there is nothing about this software on any forums
> that I have found.
>
> I like it. It is easy to use too. Has it been overrun
> by something else (like Cactus maybe??)
>

Cactus has not officially replaced it but is covering the same ground (and
some more). You can have a look at
http://jakarta.apache.org/cactus/howto_ejb.html if you wish to check how to
test EJBs with Cactus.

Thanks
-Vincent

> Kaarle Kaila
>
> __________________________________________________
> Do You Yahoo!?
> Listen to your Yahoo! Mail messages from any phone.
> http://phone.yahoo.com
>
>
> 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/
>
>
>

kentbeck@... wrote:
>
> --- In junit@y..., Berin Loritsch <bloritsch@a...> wrote:
> > I have been using JUnit 3.7 for a couple of months now, and
> > have run accross something very frustrating.  We (the Apache
> > Avalon project) use Ant to do our builds and automated testing,
> > however the behavior for test collection is different based
> > on wether a Test is a TestCase or a TestSuite.
> >
> > Your FAQ suggests that for one-time setup code you need to run
> > it in a TestSuite.
>
> This is what TestSetup is for. Wrap the suite in a subclass of
> TestSetup, override setUp() (and maybe tearDown()) in your subclass,
> and it only gets run once.
>
> Alternatively, you could consider how to untangle your design so you
> didn't need one-time setup.

I don't _need_ one-time setup, it is a matter of resources.  We have
a rather expensive setup and tear down routine that takes time.  If
it were done once for all the tests in the class then the test takes
an order of magnitude less time to run.

Also, some tests do need one time setup, the idea was to allow them
to extend one of our own framework interfaces (Initializable or
Disposable) to do their own one time setup.

The solution we have still allows the use of setUp() and tearDown()
for each test (prepare files, etc).

I can try the TestSetup -- it is probably easier to maintain.

The whole thing is that I don't want to have to set up suites specifically
for the purpose of wrapping them.

hi,

I have been able to test EJB's (in weblogic ) with a
tool called junitee
http://sourceforge.net/projects/junitee

I have not been able to contact the author about a
modification I made and it seems to be very quiet
about it. But I like this simple little servlet
interface for junit.

Kaarle Kaila


--- gopala krishnan T <talluri_krishnan@...>
wrote:
> can any body help me out in using junit or any other
> tool to test EJB's on Weblogic server6.0.or
>
> pls give me the guide lines for using cactus ,and
> its setup.
>
> an early reply is appreciated.
>
> gopala krishnan T
>
>


__________________________________________________
Do You Yahoo!?
Listen to your Yahoo! Mail messages from any phone.
http://phone.yahoo.com

Hello,

I am new to junit. I downloaded junit3.7 from junit.org site. Here the
textui and swingui packages are not there. Can anybody tell the simplest
method I will set up junit in my system(Windows 2000)and how to use it for
my JSPs and servlets and java classes.

sidd

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

-----Original Message-----
From: Daniel Reynes [mailto:daniel.reynes@...]
Sent: Tuesday, October 02, 2001 10:42 AM
To: Junit
Subject: [junit] Script with HttpUnit

I have to test some pages of a web site, and I tried to use HttpUnit. Unfortunately, it seems that JavaScript is not supported.

Does anybody know if there is another way to test these kind of pages, or if there is another software that can do the job ?

 

Thanks in advance

 

Dan

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.

Any pointers to articles or emails or whatever for using xunit to
test GUI code would be appreciated.  Thanks!
/b

http://sourceforge.net/projects/jfcunit/

http://sourceforge.net/docman/display_doc.php?docid=5200&group_id=28662


This email and any attachments are confidential and are intended only for
the addressee. If you are not the intended recipient of this email and have
received it in error, please notify the sender immediately by reply email
and then delete it from your system.


> -----Original Message-----
> From: Bill Northlich [mailto:billn@...]
> Sent: 02 October 2001 16:44
> To: junit@yahoogroups.com
> Subject: [junit] xunit for GUI?
>
>
> Any pointers to articles or emails or whatever for using xunit to
> test GUI code would be appreciated.  Thanks!
> /b
>
>
> ------------------------ Yahoo! Groups Sponsor
> ---------------------~-->
> Pinpoint the right security solution for your company- Learn
> how to add 128- bit encryption and to authenticate your web
> site with VeriSign's FREE guide!
> http://us.click.yahoo.com/yQix2C/33_CAA/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/
>
>

We've been using JUnitX at work for a long time because of its access to
private/protected stuff.  Over time, it
seems that JUnitX and JUnit have grown more different.  What I was wondering
was:

1. Does JUnit support access to private/protected?   It doesn't seem like it
from the latest Javadoc but I could be wrong.
2. Were there or are there plans for merging the features and interfaces of
these two versions?

Thanks!
noah



Noah Green
Software Engineering Manager
ThinAirApps, Inc.
(212) 343-5032
noah.green@...

This message and any appended documentation is intended only for the use of
the intended recipient(s) and is proprietary and confidential to
ThinAirApps, Inc. and may not be disclosed to third parties without the
prior written permission of ThinAirApps, Inc.  If you are not the intended
recipient, you are hereby notified that any review, retransmission,
conversion to hard copy, copying, circulation or other use of this message
and any appended documentation is strictly prohibited and may be illegal.
If you are not the intended recipient, please contact ThinAirApps, Inc. at
212-343-5000 and delete this message from your system. ThinAirApps, Inc.
owns all right, title, and interest in and to this message and any appended
documentation. Copyright (c) 2001, ThinAirApps, Inc. All rights reserved.

Kent:

You've made this suggestion a few times recently, and I was hoping you would
elaborate on it. Do you have a specific example in mind of how a TestSetup
indicated that something was wrong.

I have written an article on how singletons can defeat unit testing. I have
observed that if a test relies on the state of a singleton, then there may
be a desire to do one-time setup code and *that* is the sign of a code
smell. Can you offer a different example? I'd really like the opportunity to
learn from it.

Thanks,
JBR.


----- Original Message -----
  > Your FAQ suggests that for one-time setup code you need to run
  > it in a TestSuite.

This is what TestSetup is for. Wrap the suite in a subclass of
TestSetup, override setUp() (and maybe tearDown()) in your subclass,
and it only gets run once.

Alternatively, you could consider how to untangle your design so you
didn't need one-time setup.

Kent


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

"J. B. Rainsberger" wrote:
>
> Kent:
>
> You've made this suggestion a few times recently, and I was hoping you would
> elaborate on it. Do you have a specific example in mind of how a TestSetup
> indicated that something was wrong.
>
> I have written an article on how singletons can defeat unit testing. I have
> observed that if a test relies on the state of a singleton, then there may
> be a desire to do one-time setup code and *that* is the sign of a code
> smell. Can you offer a different example? I'd really like the opportunity to
> learn from it.

For me, it is not a question of testing singletons.  It is a question of waiting
for a configuration file to be read, a logger hierarchy to be set up, a
Component Manager
to be populated, a Context to be popluated, the test to be run, and everything
to be
torn down.  This occurs for _every_ test in the testcase.  The framework in
question
is well tested and scalable, the tests are for the Components loaded into the
Component
Manager.

Another example is testing RMI resources.  The testcase needs to set up the RMI
server code once because you will inevitably get a SocketException claiming that
the port you want to listen to is already bound.  In this case, the common
TestCase
class is not sufficient.

>
> Thanks,
> JBR.
>
> ----- Original Message -----
>  > Your FAQ suggests that for one-time setup code you need to run
>  > it in a TestSuite.
>
> This is what TestSetup is for. Wrap the suite in a subclass of
> TestSetup, override setUp() (and maybe tearDown()) in your subclass,
> and it only gets run once.
>
> Alternatively, you could consider how to untangle your design so you
> didn't need one-time setup.
>
> Kent
>
> _________________________________________________________________
> 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/

--- In junit@y..., "J. B. Rainsberger" <jbrains762@h...> wrote:
> Kent:
>
> You've made this suggestion a few times recently, and I was hoping
you would
> elaborate on it. Do you have a specific example in mind of how a
TestSetup
> indicated that something was wrong.

We had a singleton for the exchange rates. Every time we wrote the
data for a unit test we had to look up the historical figures, or
take out the existing rates temporarily. You know the drill.

The solution was not to make plugging special exchange rates easier,
it was to limit visibility of exchange rates to only those objects
that really needed them, and passing exchange rates into them either
as method parameters or constructor parameters. This enabled a bunch
of other design simplifications that we wouldn't have seen if we
hadn't forced ourselves to make test writing easier.

I'm wondering if the OP's problem isn't similar. Reading a properties
file is expensive, so we only want to do it once for a bunch of
tests. Well, what if you explicitly passed the properties you need to
the methods that need them?

Kent

-----Original Message-----
From: Dan Barthel [mailto:danbarthel@...]
Sent: Tuesday, October 02, 2001 8:43 AM
To: junit@yahoogroups.com
Subject: RE: [junit] Script with HttpUnit

There seems to be a JSUnit listed at http://xprogramming.com/software.htm Maybe that will help.

 

Dan

-----Original Message-----
From: Daniel Reynes [mailto:daniel.reynes@...]
Sent: Tuesday, October 02, 2001 10:42 AM
To: Junit
Subject: [junit] Script with HttpUnit

I have to test some pages of a web site, and I tried to use HttpUnit. Unfortunately, it seems that JavaScript is not supported.

Does anybody know if there is another way to test these kind of pages, or if there is another software that can do the job ?

 

Thanks in advance

 

Dan

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.

kentbeck@... wrote:
>
> --- In junit@y..., "J. B. Rainsberger" <jbrains762@h...> wrote:
> > Kent:
> >
> > You've made this suggestion a few times recently, and I was hoping
> you would
> > elaborate on it. Do you have a specific example in mind of how a
> TestSetup
> > indicated that something was wrong.
>
> I'm wondering if the OP's problem isn't similar. Reading a properties
> file is expensive, so we only want to do it once for a bunch of
> tests. Well, what if you explicitly passed the properties you need to
> the methods that need them?


Actually, what Avalon is doing is a bit more expensive than reading a
properties file.  The configuration data is in an XML format, that
gets read and turned into a Configuration object tree.  From this
tree, the test environment's Context is populated, the Logger hierarchy
is set up, and the ComponentManager is populated with the Components
that we will be testing.  This ensures that the Components play well
with the rest of the system that has been well tested and run under
load.

The TestCases we have then lets each test run against this setup.
The way I have "bent" the JUnit framework to work with mine works
for this solution.  Basically my test environment is set up once
per TestCase object and torn down once per TestCase object.  Each
TestCase needs to have its own environment so this works well.

I'm not sure what Kent had in mind, but:

In the first set of situations you mention (Logger hierarchies, config
files, etc), these can often be dealt with by stubbing out these
components.

For example, although an application may use a complex logging
hierarchy which routes different classes of messages to different files or
hosts, the testcases are handed a Logger with a single listener which
sends output to a single local file which is appropriately labelled and
filed. Having this setup run for each test method does not slow my
testcases down appreciably. It doesn't matter to the testcases where the
Logger actually sends its output to- just that there is something there to
accept events. I have a LoggerTestCase which performs this setup for me
and I just don't worry about it.

The issue is similar with config files. Most testcases don't care where
the configuration data comes from. I just create a Map as a fixture which
contains exactly what is needed for particular testcases. My code doesn't
care what mechanism was used to populate the Map or what 10 gazillion
other values might be available. The actual process of interpreting the
config files or database or whatever is in a separate package and
independently tested.

I think the design issue is making your classes much less dependent on the
global state. Singletons are just one aspect of that. If these components
are hidden behind nice interfaces, then you have a lot of freedom to
decide just how much initialization is needed and can dumnmy out a lot of
extra complexity.

RMI *is* an issue and is one of the places I have had significant problems
with per-testcase fixtures. This and other testing issues led to me
dramatically reducing my use of RMI.

On Tue, 2 Oct 2001, Berin Loritsch wrote:

> "J. B. Rainsberger" wrote:
> >
> > Kent:
> >
> > You've made this suggestion a few times recently, and I was hoping you would
> > elaborate on it. Do you have a specific example in mind of how a TestSetup
> > indicated that something was wrong.
> >
> > I have written an article on how singletons can defeat unit testing. I have
> > observed that if a test relies on the state of a singleton, then there may
> > be a desire to do one-time setup code and *that* is the sign of a code
> > smell. Can you offer a different example? I'd really like the opportunity to
> > learn from it.
>
> For me, it is not a question of testing singletons.  It is a question of
waiting
> for a configuration file to be read, a logger hierarchy to be set up, a
Component Manager
> to be populated, a Context to be popluated, the test to be run, and everything
to be
> torn down.  This occurs for _every_ test in the testcase.  The framework in
question
> is well tested and scalable, the tests are for the Components loaded into the
Component
> Manager.
>
> Another example is testing RMI resources.  The testcase needs to set up the
RMI
> server code once because you will inevitably get a SocketException claiming
that
> the port you want to listen to is already bound.  In this case, the common
TestCase
> class is not sufficient.
>
> >
> > Thanks,
> > JBR.
> >
> > ----- Original Message -----
> >  > Your FAQ suggests that for one-time setup code you need to run
> >  > it in a TestSuite.
> >
> > This is what TestSetup is for. Wrap the suite in a subclass of
> > TestSetup, override setUp() (and maybe tearDown()) in your subclass,
> > and it only gets run once.
> >
> > Alternatively, you could consider how to untangle your design so you
> > didn't need one-time setup.
> >
> > Kent
> >
> > _________________________________________________________________
> > 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/
>
>
> 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

Eric Vought wrote:
>
> I'm not sure what Kent had in mind, but:
>
> In the first set of situations you mention (Logger hierarchies, config
> files, etc), these can often be dealt with by stubbing out these
> components.
>
> For example, although an application may use a complex logging
> hierarchy which routes different classes of messages to different files or
> hosts, the testcases are handed a Logger with a single listener which
> sends output to a single local file which is appropriately labelled and
> filed. Having this setup run for each test method does not slow my
> testcases down appreciably. It doesn't matter to the testcases where the
> Logger actually sends its output to- just that there is something there to
> accept events. I have a LoggerTestCase which performs this setup for me
> and I just don't worry about it.
>
> The issue is similar with config files. Most testcases don't care where
> the configuration data comes from. I just create a Map as a fixture which
> contains exactly what is needed for particular testcases. My code doesn't
> care what mechanism was used to populate the Map or what 10 gazillion
> other values might be available. The actual process of interpreting the
> config files or database or whatever is in a separate package and
> independently tested.
>
> I think the design issue is making your classes much less dependent on the
> global state. Singletons are just one aspect of that. If these components
> are hidden behind nice interfaces, then you have a lot of freedom to
> decide just how much initialization is needed and can dumnmy out a lot of
> extra complexity.

The thing to reiterate is that we are testing Components that live in a
specific environment, and we must make sure they play nice in that environment.
This makes sure that changes to the environment don't break the Components,
and vice versa.  You can't test that with dummy stuff.

Not all our testcases use this heavy process--Only the testcases that test
Components.  We have a lot of helper classes that we test individually--without
the extra bulk.

Sometime during the test cycle we need to perform the environment tests, so
I would rather do it with JUnit than with a production system ;).

> RMI *is* an issue and is one of the places I have had significant problems
> with per-testcase fixtures. This and other testing issues led to me
> dramatically reducing my use of RMI.

I don't typically use RMI in most cases, however we do have a component that
exposes an RMI interface, so we need to test it.

Can I remind everyone that the initial request was for TestSuite to inherit
from Assert just like TestCase does.  I had a couple other alternatives,
but I am not trying to drastically change the JUnit framework.

Berin Loritsch wrote:
>
> Eric Vought wrote:
> >
> > I'm not sure what Kent had in mind, but:
> >
> > In the first set of situations you mention (Logger hierarchies, config
> > files, etc), these can often be dealt with by stubbing out these
> > components.
> >
> > For example, although an application may use a complex logging
> > hierarchy which routes different classes of messages to different files or
> > hosts, the testcases are handed a Logger with a single listener which
> > sends output to a single local file which is appropriately labelled and
> > filed. Having this setup run for each test method does not slow my
> > testcases down appreciably. It doesn't matter to the testcases where the
> > Logger actually sends its output to- just that there is something there to
> > accept events. I have a LoggerTestCase which performs this setup for me
> > and I just don't worry about it.
> >
> > The issue is similar with config files. Most testcases don't care where
> > the configuration data comes from. I just create a Map as a fixture which
> > contains exactly what is needed for particular testcases. My code doesn't
> > care what mechanism was used to populate the Map or what 10 gazillion
> > other values might be available. The actual process of interpreting the
> > config files or database or whatever is in a separate package and
> > independently tested.
> >
> > I think the design issue is making your classes much less dependent on the
> > global state. Singletons are just one aspect of that. If these components
> > are hidden behind nice interfaces, then you have a lot of freedom to
> > decide just how much initialization is needed and can dumnmy out a lot of
> > extra complexity.
>
> The thing to reiterate is that we are testing Components that live in a
> specific environment, and we must make sure they play nice in that
environment.
> This makes sure that changes to the environment don't break the Components,
> and vice versa.  You can't test that with dummy stuff.
>
> Not all our testcases use this heavy process--Only the testcases that test
> Components.  We have a lot of helper classes that we test
individually--without
> the extra bulk.
>
> Sometime during the test cycle we need to perform the environment tests, so
> I would rather do it with JUnit than with a production system ;).
>
> > RMI *is* an issue and is one of the places I have had significant problems
> > with per-testcase fixtures. This and other testing issues led to me
> > dramatically reducing my use of RMI.
>
> I don't typically use RMI in most cases, however we do have a component that
> exposes an RMI interface, so we need to test it.
>
>
> 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/

Ah. So these are actually (more or less) functional tests, where you have
separate lighter-weight unit tests.

On Tue, 2 Oct 2001, Berin Loritsch wrote:

> Eric Vought wrote:
> >
> > I'm not sure what Kent had in mind, but:
> >
> > In the first set of situations you mention (Logger hierarchies, config
> > files, etc), these can often be dealt with by stubbing out these
> > components.
> >
> > For example, although an application may use a complex logging
> > hierarchy which routes different classes of messages to different files or
> > hosts, the testcases are handed a Logger with a single listener which
> > sends output to a single local file which is appropriately labelled and
> > filed. Having this setup run for each test method does not slow my
> > testcases down appreciably. It doesn't matter to the testcases where the
> > Logger actually sends its output to- just that there is something there to
> > accept events. I have a LoggerTestCase which performs this setup for me
> > and I just don't worry about it.
> >
> > The issue is similar with config files. Most testcases don't care where
> > the configuration data comes from. I just create a Map as a fixture which
> > contains exactly what is needed for particular testcases. My code doesn't
> > care what mechanism was used to populate the Map or what 10 gazillion
> > other values might be available. The actual process of interpreting the
> > config files or database or whatever is in a separate package and
> > independently tested.
> >
> > I think the design issue is making your classes much less dependent on the
> > global state. Singletons are just one aspect of that. If these components
> > are hidden behind nice interfaces, then you have a lot of freedom to
> > decide just how much initialization is needed and can dumnmy out a lot of
> > extra complexity.
>
> The thing to reiterate is that we are testing Components that live in a
> specific environment, and we must make sure they play nice in that
environment.
> This makes sure that changes to the environment don't break the Components,
> and vice versa.  You can't test that with dummy stuff.
>
> Not all our testcases use this heavy process--Only the testcases that test
> Components.  We have a lot of helper classes that we test
individually--without
> the extra bulk.
>
> Sometime during the test cycle we need to perform the environment tests, so
> I would rather do it with JUnit than with a production system ;).
>
> > RMI *is* an issue and is one of the places I have had significant problems
> > with per-testcase fixtures. This and other testing issues led to me
> > dramatically reducing my use of RMI.
>
> I don't typically use RMI in most cases, however we do have a component that
> exposes an RMI interface, so we need to test it.
>
>
> 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

Sounds like your doing integration testing then and not unit testing. It's
understandable that your needs would differ and you would need to "bend"
junit to make this work. Here at Terraspring, we have also made considerable
enhancements in order to use it for integration testing. But we have
separated out our unit tests from our integration tests because they often
have different needs.

chris

-----Original Message-----
From: Berin Loritsch [mailto:bloritsch@...]
Sent: Tuesday, October 02, 2001 12:28 PM
To: junit@yahoogroups.com
Subject: Re: [junit] Tangled design (Re: Test framework improvement)


The thing to reiterate is that we are testing Components that live in a
specific environment, and we must make sure they play nice in that
environment.
This makes sure that changes to the environment don't break the Components,
and vice versa.  You can't test that with dummy stuff.

Not all our testcases use this heavy process--Only the testcases that test
Components.  We have a lot of helper classes that we test
individually--without
the extra bulk.

Sometime during the test cycle we need to perform the environment tests, so
I would rather do it with JUnit than with a production system ;).

Eric Vought wrote:
>
> Ah. So these are actually (more or less) functional tests, where you have
> separate lighter-weight unit tests.

Exactly.  The test excersize the interfaces of the Component and makes sure
it behaves within the environment.

In a way, it might be both at once.  We have extended JUnit's TestCase to
make what we want work.  It would just be easier to that by extending
TestSuite instead of TestCase.

>
> On Tue, 2 Oct 2001, Berin Loritsch wrote:
>
> > Eric Vought wrote:
> > >
> > > I'm not sure what Kent had in mind, but:
> > >
> > > In the first set of situations you mention (Logger hierarchies, config
> > > files, etc), these can often be dealt with by stubbing out these
> > > components.
> > >
> > > For example, although an application may use a complex logging
> > > hierarchy which routes different classes of messages to different files or
> > > hosts, the testcases are handed a Logger with a single listener which
> > > sends output to a single local file which is appropriately labelled and
> > > filed. Having this setup run for each test method does not slow my
> > > testcases down appreciably. It doesn't matter to the testcases where the
> > > Logger actually sends its output to- just that there is something there to
> > > accept events. I have a LoggerTestCase which performs this setup for me
> > > and I just don't worry about it.
> > >
> > > The issue is similar with config files. Most testcases don't care where
> > > the configuration data comes from. I just create a Map as a fixture which
> > > contains exactly what is needed for particular testcases. My code doesn't
> > > care what mechanism was used to populate the Map or what 10 gazillion
> > > other values might be available. The actual process of interpreting the
> > > config files or database or whatever is in a separate package and
> > > independently tested.
> > >
> > > I think the design issue is making your classes much less dependent on the
> > > global state. Singletons are just one aspect of that. If these components
> > > are hidden behind nice interfaces, then you have a lot of freedom to
> > > decide just how much initialization is needed and can dumnmy out a lot of
> > > extra complexity.
> >
> > The thing to reiterate is that we are testing Components that live in a
> > specific environment, and we must make sure they play nice in that
environment.
> > This makes sure that changes to the environment don't break the Components,
> > and vice versa.  You can't test that with dummy stuff.
> >
> > Not all our testcases use this heavy process--Only the testcases that test
> > Components.  We have a lot of helper classes that we test
individually--without
> > the extra bulk.
> >
> > Sometime during the test cycle we need to perform the environment tests, so
> > I would rather do it with JUnit than with a production system ;).
> >
> > > RMI *is* an issue and is one of the places I have had significant problems
> > > with per-testcase fixtures. This and other testing issues led to me
> > > dramatically reducing my use of RMI.
> >
> > I don't typically use RMI in most cases, however we do have a component that
> > exposes an RMI interface, so we need to test it.
> >
> >
> > 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
>
>
> 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/

say there's a package named "com.foo" containing the class Bar.java
Bar.java has a package-level access constructor.
We have unit tests inside "com.foo.tests".
Is it possible to instantiate a Bar object in a test from com.foo.tests?
Is this what TestCase.newInstance is used for?

Thanks

-Mark

What I did was to create a bridge class in that package that does all the
package level calls.

e.g.
package com.foo;

public class BridgeClass {
public Bar static createBar() {
     return new Bar();
}

I can do this because I have two source path, one under "src" as the source code
for the application, and another one under
"test" as the source code for the test code.  So I can put my testing classes
(Along with all the bridge classes and mock
objects) in the same package as the tested ones.  When I need to do the build,
I'll just remove the 'test' from the source path
and do a clean build.

However, you seem to have your test classes in different package so I am not
sure if this apply for you.

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


"Sainz, Mark" wrote:

> say there's a package named "com.foo" containing the class Bar.java
> Bar.java has a package-level access constructor.
> We have unit tests inside "com.foo.tests".
> Is it possible to instantiate a Bar object in a test from com.foo.tests?
> Is this what TestCase.newInstance is used for?
>
> Thanks
>
> -Mark
>
>
> 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/

In our projects, we just have two source paths, "src" and "bvt" (Build
Verification Tests). Code from src is compiled into "class" and code from
bvt is compiled into "bvtclass". In the bvt directory, we simply duplicate
the src package hierarchy, such that
com.qlue.apps.inventory.dblayer.Entity has its tests in
com.qlue.apps.inventory.dblayer.EntityTest. In our ANT config file, we
have targets to build and clean the two trees. Only the src path is
packaged in the JAR.

If you set it up this way, then all your test classes have access to the
package protected members without having to write any bridge code.

On Tue, 2 Oct 2001, Sainz, Mark wrote:

>
> say there's a package named "com.foo" containing the class Bar.java
> Bar.java has a package-level access constructor.
> We have unit tests inside "com.foo.tests".
> Is it possible to instantiate a Bar object in a test from com.foo.tests?
> Is this what TestCase.newInstance is used for?
>
> Thanks
>
> -Mark
>
>
> 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

Kent:

The design strategy you have suggested is one that I have, I suppose,
"independently discovered" as a good way to make unit testing easier. (In
other words, I didn't have an experienced person standing by me on day 1
saying, "Do it this way.") If class A only cares about one or two pieces of
information normally managed by class B, then A does not need to depend on
B. The application ought perhaps to give to A the parts of B it needs.

This makes me wonder whether the OP is truly trying to unit test with JUnit,
or do integration testing. What do you say, OP?

JBR.


----- Original message -----
  > You've made this suggestion a few times recently, and I was hoping
you would
  > elaborate on it. Do you have a specific example in mind of how a
TestSetup
  > indicated that something was wrong.

We had a singleton for the exchange rates. Every time we wrote the
data for a unit test we had to look up the historical figures, or
take out the existing rates temporarily. You know the drill.

The solution was not to make plugging special exchange rates easier,
it was to limit visibility of exchange rates to only those objects
that really needed them, and passing exchange rates into them either
as method parameters or constructor parameters. This enabled a bunch
of other design simplifications that we wouldn't have seen if we
hadn't forced ourselves to make test writing easier.

I'm wondering if the OP's problem isn't similar. Reading a properties
file is expensive, so we only want to do it once for a bunch of
tests. Well, what if you explicitly passed the properties you need to
the methods that need them?

Kent


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

Aha! So you are doing integration/acceptance testing and not unit testing.
Now everything makes sense. Expectations are different.

Still, I would think you could use a thin object to shield the actual
component from the environment. I work in an identical environment -- for a
while, there, I thought you worked on my project. :) I have a "shield" that
handles all the nasty stuff about where to get configuration information and
how to translate my logging requests into logging requests for the framework
and all that, and my actual component code can run outside the framework.
Doing so makes it so much easier to write unit tests for the "real code" and
I guess I have to live with how tough it is to test the component shield
object. Try as I might, they won't let me refactor the framework...

So you could build a bridge, if that helps you. It might be easy.

JBR.
----- Original message -----
The thing to reiterate is that we are testing Components that live in a
specific environment, and we must make sure they play nice in that
environment.

[...]


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