> Thanks for the reply.  Your proposed solution would not solve the problem
I
> am trying to address.  My situation is the following:
>
> 1. My test method throws an exception.  This exception indicates the real
> problem.
> 2. My tearDown method throws an exception.  This exception is caused by an
> invalid state because my test method did not run all way through.
>
> This is a problem because of #2.  The way the JUnit framework is written,
> any exception coming out of tearDown will mask any exception coming out of
a
> test method.

As Kent would say, this sounds like an opportunity to improve your design.
Is there something you can do about tearDown() so that it doesn't throw an
exception whenever the test fails? Any code that tears down fixture should
really only fail if there's a low-level problem you can't control (network
transport, database connection, that kind of thing). Maybe you're doing too
much to set up and tear down your test fixture.

JBR.

> Hello -
>
> When I run JUnit, where does it consider the top or root level directory?

I found it better to avoid the problem entirely. You should not let yourself
rest at the whim of the JUnit developers, nice guys though they are.
Consider passing a JVM property to the TestRunner like "test.root" and use
THAT as your "root".

Example:

java -Dtest.root=c:/myRoot junit.textui.TestRunner MyTestCase

public class MyTestCase extends TestCase {
     ...
     protected File root() {
         return new File(System.getProperty("test.root", "/"));
     }
     ....
     public void testSomething() {
         File button = new File(root(), "/images/testcases/button.gif");
         ....
     }
}

You can use the File object to create an absolute path from your relative
paths.

What do you think? Now your tests run anywhere and you can put the files you
need anywhere.

JBR.

HAI,
     Designing the whole test process.

Step1:subclass the TestCase.
Step2:Initailize
Step3:Add testXXX() methods.
Step4:If reqiured run repeated tests.
Step5:Collect Result in Junit coding itself using TestResult
Step6:tearDown.

Can anyone send an illustrated code example for the above the  testing process.
This will help in understanding the junit in a better way for newbie's.

thank u & regards
Suresh.S


-------------------------------------------------
This mail helped a tree grow. Know more at http://green.sify.com

Want to win a PC or Palm Tops or Digital Diaries or T-Shirts?
Click here http://promos.sify.com/niit/main.asp?mail

One thing that I see often is the fact that JUnit works
from the command line, but not from the swing version.
Veterans of JUnit are aware that this is a classloader
issue.  There is a way to turn off the new classloader
per test behavior.

I assert that this is not a proper testing environment.
It is not analogous to real situations, and leads to
false negatives.  No real world classloader environment
I am aware of behaves like that of JUnit's Swing
TestRunner.  What this leads people to do is work around
the buggy classloader.  This is not what should be
happening IMNSHO.

I propose that JUnit should provide a consistent
classloading environment, or scrap the whole alternate
ClassLoader environment altogether.  I consider it a
bug in the test framework if the results of the test
are different based on how I execute the TestRunner.
This needs to be remedied soon.  The ClassLoader is
buggy if it does not behave according to normal
classloaders (like URLClassLoader as the yardstick).

--

"Those who would trade liberty for
  temporary security deserve neither"
                 - Benjamin Franklin

--- Berin Loritsch <bloritsch@...> wrote:
> I assert that this is not a proper testing environment.
> It is not analogous to real situations, and leads to
> false negatives.  No real world classloader environment

I assert that it is almost a proper testing environment. For many, if
not most, JUnit users, the class loading tests work and work better
than the alternative because they allow a developer to leave the Swing
UI running and rerun an individual test after changing it in the IDE.
As the usage of JUnit expans, many people run the Swing UI in what I
would consider strange environments. I often wonder why they aren't
just running the textui, but I digress. Since those environment are
common, and the loading behavior introduces problems it would probably
be best to change the Swing UI to default to noloading. Eliminating the
class loading behavior would be a huge disservice to the devlopers who
use it daily to increase their feedback by running tests while coding.

Regards,

Rob


__________________________________________________
Do You Yahoo!?
Find a job, post your resume.
http://careers.yahoo.com

Robert Sartin wrote:
>
> --- Berin Loritsch <bloritsch@...> wrote:
> > I assert that this is not a proper testing environment.
> > It is not analogous to real situations, and leads to
> > false negatives.  No real world classloader environment
>
> I assert that it is almost a proper testing environment. For many, if
> not most, JUnit users, the class loading tests work and work better
> than the alternative because they allow a developer to leave the Swing
> UI running and rerun an individual test after changing it in the IDE.
> As the usage of JUnit expans, many people run the Swing UI in what I
> would consider strange environments. I often wonder why they aren't
> just running the textui, but I digress. Since those environment are
> common, and the loading behavior introduces problems it would probably
> be best to change the Swing UI to default to noloading. Eliminating the
> class loading behavior would be a huge disservice to the devlopers who
> use it daily to increase their feedback by running tests while coding.

"Almost" and "Are" can sometimes be a mile apart.  Defaulting to the
"-nonloading" option is a step in the right direction.  However, what
about this possibility:

The same classloader is run for all tests.  When the Swing runner is asked
to re-run a test or group of tests, create a new Classloader for the
environment.

The important thing here is consistency.  In this situation, we do not
have a new ClassLoader for each individual *Test* (which may be simply
another method in the same class).  We have a new ClassLoader for each
individual *Run*.  This provides the flexibility the users want, AND
the stable environment everyone craves.

Have you guys considered that route and run into snags?

--

"Those who would trade liberty for
  temporary security deserve neither"
                 - Benjamin Franklin

I have a couple of testing best practices questions for the group.

If I am doing operator overloading (polymorphism) what is an acceptable
way to construct the tests in JUnit so that I can tell which method
passes or fails?  For example:
	 int add(int a, int b){
		 return (a+b);
	 }

	 double add(double a, double b) {
		 return (a+b);
	 }

	 float add(float a, float b) {
		 return (a+b);
	 }

I need a test called testAdd().  I have to test all of them from this
method right?  How I can which one fails?

My next question has to do with testing sub classes.  If I have a
framework api with a class, MyBaseClass, and in a project I define
MyProjectClass extends MyBaseClass.  Would you want to write tests for
methods defined in MyBaseClass?  Is this situation dependant or should
you never/always write them?

Thanks,
Earl
earl.hokens@...

On Fri, 2 Nov 2001, Earl Hokens wrote:

> I have a couple of testing best practices questions for the group.
>
> If I am doing operator overloading (polymorphism) what is an acceptable
> way to construct the tests in JUnit so that I can tell which method
> passes or fails?  For example:
>  int add(int a, int b){
> 	 return (a+b);
>  }
>
>  double add(double a, double b) {
> 	 return (a+b);
>  }
>
>  float add(float a, float b) {
> 	 return (a+b);
>  }
>
> I need a test called testAdd().  I have to test all of them from this
> method right?  How I can which one fails?

Your test methods don't have to mathc your method names. In other words,
there is no restriction that testAdd() and only testAdd() tests the method
"add". We use the method name as a base and then add additional info to
it:

testAddIntInt()
testAddDoubleDouble()

Typically, you will have more than one test per method, testing different
entry conditions:

testEqualsEmptyInstance()
testEqualsWNull()
testEqualsWIdentity()

etc.

> My next question has to do with testing sub classes.  If I have a
> framework api with a class, MyBaseClass, and in a project I define
> MyProjectClass extends MyBaseClass.  Would you want to write tests for
> methods defined in MyBaseClass?  Is this situation dependant or should
> you never/always write them?

If we control the base class, we always write an abstract TestCase when we
write the base class. If it is a third party base class (or interface),
then we will often create an appropriate abstract TestCase against their
base class, though sometimes we will go back and add it later in a round
of refactoring. With standard library classes, it is convenient to keep a
small collection of abstract TestCases somewhere that can be reused from
project to project (e.g. for Enumeration, Iterator, Collection).

Creating the test case for a 3rd party base class accomplishes two
things. You can run the test (possibly with the help of a trivial stub)
against their code to detect bugs, misunderstandings, and behavior
changes. You also get a much better indication that the classes you create
will interact correctly with their library (or, at least, that you can
demonstrate where the fault lies). Implementing this test case can be used
as a first exploration of a new toolkit/base class to ensure that you
understand both what it is supposed to do and what it actually does
before you build your code around it.

>
> Thanks,
> Earl
> earl.hokens@...
>
>
> 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

hai,

     After storing the result in an object of type  Test
Result..what is the method that can be used to print it?
Can anyone expalin?

Thank U & Regards
Suresh.S

-------------------------------------------------
This mail helped a tree grow. Know more at http://green.sify.com

Want to win a PC or Palm Tops or Digital Diaries or T-Shirts?
Click here http://promos.sify.com/niit/main.asp?mail

> hai,
>
>     After storing the result in an object of type  Test
> Result..what is the method that can be used to print it?
> Can anyone expalin?
>
> Thank U & Regards
> Suresh.S

Have you looked at both the API documentation and the source that comes with
JUnit? If it's not there, and you can't do it yourself, it can't be done.

JBR.

-----

I do not know if all the class should do unit test.

Some class do not process the real action espc in the large framework.

-----Original Message-----
From: Paolo Perrotta [mailto:pperrotta@...]
Sent: Monday, November 05, 2001 4:29 AM
To: junit@yahoogroups.com
Subject: Re: [junit] Who can tell me the scape of unit test of class.

Can you submit an example of a class that you think should *not* be unit tested?

 

-----

I do not know if all the class should do unit test.

Some class do not process the real action espc in the large framework.

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.

Maybe the question is better "independently unit tested." It is not

unusual to define helper classes such as "value classes" or

"enumeration classes." IMHO, adequate test coverage for helper

classes is generally achieved via the unit tests that address logic/state-

management classes that in turn use these helper classes.

Can you submit an example of a class that you think should *not* be unit tested?

>> can't find any junit.properties file on the system.
>> Do you have any information about this?

I am not sure if you got your answer, but JUnit looks for that file to be in
a system environment variable called user.home.  One Windows 2000 (and I
suspect NT) this maps to the environment variable: USERPROFILE.  Just store
the file there and it works fine.

Another alternative is to in essence over-ride by setting this on the java
call like the following:

	 java -Duser.home=c:\temp My_TEST

If you do not want to override this variable, the you can change the code in
the junit.runner.BaseTestRunner's getPreferencesFile() method to use your
own defined method.

Personally, I think that JUnit should use something like junit.home for this
variable because on Windows platforms you typically do not work out of your
home directory like you do on Unix.

Ron DiFrango

-----Original Message-----
From: Bret Waldow [mailto:Bret.Waldow@...]
Sent: Monday, October 29, 2001 7:45 PM
To: 'junit@yahoogroups.com'
Subject: RE: [junit] jUnit bug? textui - no errors, gui - errors.


>> can't find any junit.properties file on the system.
>> Do you have any information about this?

> My system has one. I assume JUnit creates it automatically. Perhaps you
have
> an old version of JUnit, or maybe the directory that Java thinks is your
home
> directory isn't writable.

Odd.  I'm running jUnit 3.7, and the permissions on my local directory in
WINNT\Profile are open to all.

I suspect the system might maintain some network directory as my "home" that
I don't know about?

Bret


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/


**************************************************************************
The information transmitted herewith is sensitive information intended only
for use by the individual or entity to which it is addressed. If the reader
of this message is not the intended recipient, you are hereby notified that
any review, retransmission, dissemination, distribution, copying or other
use of, or taking of any action in reliance upon this information is
strictly prohibited. If you have received this communication in error,
please contact the sender and delete the material from your computer.

-----Original Message-----
From: Daniel Reynes [mailto:daniel.reynes@...]
Sent: Monday, November 05, 2001 8:27 AM
To: Junit
Subject: [junit] Catching a stop program in JBuilder

I use JBuilder 4 to run some tests with Juint.

Sometimes I want to stop running these tests and I use the Stop button of JBuilder.

But I would like to catch this action in order to be able to stop the tests where I want.

 

Does anybody know how to do this ?

 

Dan

 

P.S. Sorry if this is not the good place to ask this kind of question.

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.

How about a class that can't possibly break?  Say a class with only setters
and getters?

> ----------
> From:  Paolo Perrotta[SMTP:pperrotta@...]
> Reply To:  junit@yahoogroups.com
> Sent:  Monday, November 05, 2001 3:29 AM
> To:  junit@yahoogroups.com
> Subject:  Re: [junit] Who can tell me the scape of unit test of class.
>
> Can you submit an example of a class that you think should *not* be unit
> tested?
>
>
>  -----
>
>  I do not know if all the class should do unit test.
>  Some class do not process the real action espc in the large
> framework.
>
>
> 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
> <http://docs.yahoo.com/info/terms/>.
>

Can still break - only through extremely silly error maybe , but nonetheless
if you were relying on your unit tests to show error this could mess you up
for a bit..
Yes, this is experience talking..;-)
joe

> -----Original Message-----
> From: Kelso, JP Phil (5502) [mailto:kelsojp@...]
> Sent: 05 November 2001 16:55
> To: 'junit@yahoogroups.com'
> Subject: RE: [junit] Who can tell me the scape of unit test of class.
>
>
> How about a class that can't possibly break?  Say a class
> with only setters
> and getters?
>
> > ----------
> > From:  Paolo Perrotta[SMTP:pperrotta@...]
> > Reply To:  junit@yahoogroups.com
> > Sent:  Monday, November 05, 2001 3:29 AM
> > To:  junit@yahoogroups.com
> > Subject:  Re: [junit] Who can tell me the scape of unit
> test of class.
> >
> > Can you submit an example of a class that you think should
> *not* be unit
> > tested?
> >
> >
> >  -----
> >
> >  I do not know if all the class should do unit test.
> >  Some class do not process the real action espc in the large
> > framework.
> >
> >
> > 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
> > <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/
>
>

This e-mail and any attachment is for authorised use by the intended
recipient(s) only.  It may contain proprietary material, confidential
information and/or be subject to legal privilege.  It should not be copied,
disclosed to, retained or used by, any other party.  If you are not an intended
recipient then please promptly delete this e-mail and any attachment and all
copies and inform the sender.  Thank you.

Your test case verifies that you don't lose functionality.
Simple classes can break too. Especially if you use cut and paste to
create the setters/getters:

public class Point
{
	 private int d_x;
	 private int d_y;

	 public int getX() {return d_x;}
	 public void setX(int x) {d_x = x;}

	 public int getY() {return d_y;}
	 public void setY(int y) {d_x = y;}
} // class Point

There is also the possibility that the simple class will become more
complex or be refactored in some way later (like calculating a value).
Your test case verifies that you don't lose functionality.

On Mon, 5 Nov 2001, Kelso, JP Phil (5502) wrote:

> How about a class that can't possibly break?  Say a class with only setters
> and getters?
>
> > ----------
> > From:  Paolo Perrotta[SMTP:pperrotta@...]
> > Reply To:  junit@yahoogroups.com
> > Sent:  Monday, November 05, 2001 3:29 AM
> > To:  junit@yahoogroups.com
> > Subject:  Re: [junit] Who can tell me the scape of unit test of class.
> >
> > Can you submit an example of a class that you think should *not* be unit
> > tested?
> >
> >
> >  -----
> >
> >  I do not know if all the class should do unit test.
> >  Some class do not process the real action espc in the large
> > framework.
> >
> >
> > 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
> > <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

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

From: Paolo Perrotta

To: junit@yahoogroups.com

Sent: Monday, November 05, 2001 5:29 PM

Subject: Re: [junit] Who can tell me the scape of unit test of class.

Can you submit an example of a class that you think should *not* be unit tested?

 

-----

I do not know if all the class should do unit test.

Some class do not process the real action espc in the large framework.

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.

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

From: Eric Vought

To: 'junit@yahoogroups.com'

Sent: Tuesday, November 06, 2001 2:11 AM

Subject: RE: [junit] Who can tell me the scape of unit test of class.

Your test case verifies that you don't lose functionality.
Simple classes can break too. Especially if you use cut and paste to
create the setters/getters:

public class Point
{
      private int d_x;
      private int d_y;

      public int getX() {return d_x;}
      public void setX(int x) {d_x = x;}

      public int getY() {return d_y;}
      public void setY(int y) {d_x = y;}
} // class Point

There is also the possibility that the simple class will become more
complex or be refactored in some way later (like calculating a value).
Your test case verifies that you don't lose functionality.

On Mon, 5 Nov 2001, Kelso, JP Phil (5502) wrote:

> How about a class that can't possibly break?  Say a class with only setters
> and getters?
>
> > ----------
> > From:       Paolo Perrotta[SMTP:pperrotta@...]
> > Reply To:       junit@yahoogroups.com
> > Sent:       Monday, November 05, 2001 3:29 AM
> > To:       junit@yahoogroups.com
> > Subject:       Re: [junit] Who can tell me the scape of unit test of class.
> >
> > Can you submit an example of a class that you think should *not* be unit
> > tested?
> >
> >
> >       -----
> >
> >       I do not know if all the class should do unit test.
> >       Some class do not process the real action espc in the large
> > framework.
> >
> >
> > 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
> > <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


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.

i have been assigned the task of pushing our development team toward
unit testing.  i have been working with junit for a few weeks now but
continue to struggle with one issue.  it seems to me there is tension
between unit testing and my preferred api.  for a given class i would
like to expose only a handful of methods, yet do not want to forfeit
testing my private methods.  my feeling is that i should be concerned
with continually testing those methods, and yet fail to see why i
should expose methods which are meaningless outside the "blackbox".

perhaps i am missing something obvious about good design.  in the
mean time i have set up a simple interface which classes i test
internally must implement.

public interface Testable
{
	 public static final boolean INTERNAL_MODE = true;

	 public void runInternalTests() throws Exception;
}

this allows me to run internal tests and handle assertions by calling
the static methods of Assert.  INTERNAL_MODE must be checked within
runInternalTests().  This allows internal testing to be turned off
for production builds.

any insight about this dilemna would be appreciated.

Hello,

I'm pretty new to java, so please excuse a dumb question.

If got a class to test, my setup is something like

public class InformationDirectoryTest extends TestCase {
  SomeClass obj;

  public InformationDirectoryTest(String name) {
	 super(name);
  }
  public static Test suite()  {
	 return new TestSuite(InformationDirectoryTest.class);
  }
  public void setUp() {
     // create obj
  }
  public void tearDown() {
     // delete obj
  }

}

setUp and tear down are used for each testcase, but it would be enough
to run them once. There is an example in the FAQ but I couldn't find
out, how to get it running.

Thanks for any help, Carsten


--
Dipl. Ing. Carsten Zerbst         |   carsten.zerbst@...

Hi Carsten!

Have a look at the faq-subdirectory in the JUnit documentation.
There you will find:

public static Test suite() {
   TestSuite suite= new TestSuite();
   ...add your tests and suites here...
   TestSetup wrapper= new TestSetup(suite) {
    public void setUp() {
     oneTimeSetUp();
    }
   };
   return wrapper;
}

Dr. Oliver Strebel

CC IT QU D
Windmuhlstr. 14
Raum 2.062
60301 Frankfurt

Tel.: 069/26316924
Fax: 069/26311838

E-Mail: Oliver.Strebel@...

The opinions herein are my own and do not necessarily reflect those of
Dresdner Bank AG.


-----Ursprungliche Nachricht-----
Von: Carsten Zerbst [mailto:carsten.zerbst@...]
Gesendet: Dienstag, 6. November 2001 16:54
An: junit@yahoogroups.com
Betreff: [junit] Setup


Hello,

I'm pretty new to java, so please excuse a dumb question.

If got a class to test, my setup is something like

public class InformationDirectoryTest extends TestCase {
  SomeClass obj;

  public InformationDirectoryTest(String name) {
	 super(name);
  }
  public static Test suite()  {
	 return new TestSuite(InformationDirectoryTest.class);
  }
  public void setUp() {
     // create obj
  }
  public void tearDown() {
     // delete obj
  }

}

setUp and tear down are used for each testcase, but it would be enough
to run them once. There is an example in the FAQ but I couldn't find
out, how to get it running.

Thanks for any help, Carsten


--
Dipl. Ing. Carsten Zerbst         |   carsten.zerbst@...



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/

Typically, the way you accomplish both objectives (hiding functionality
and exposing it for unit testing) is to use a Facade. You expose the
methods that you want available for testing within the package (package
private methods and/or classes). You create a public class (the Facade)
which exposes just the methods (for the package) you want. You hide the
actual classes you return from the Facade behind simple interfaces. Your
test classes are declared in the same package as your code and therefore
have access to the package protected functionality.

The second option you suggest runInternalTests(..) is also a good thing to
do. We call our equivalent interface InvariantsChecker and the method
checkInvariants(). We use this method to ensure that an object is in an
internally consistent state (e.g. that a stack's top index does not
exceed the capacity of the underlying array). You can then call this
method from within your test code:

void testPop() throws Exception
{
	 d_stack.push(d_item1);
	 d_stack.checkInvariants();

	 Object poppedItem = stack.pop();
	 d_stack.checkInvariants();

	 assertSame(item1, poppedItem);
} // testPop()

With a little care, you can have runInternalTests() or checkInvariants()
run recursively to run consistency checks on contained or referenced
components. The key is to make sure the checks terminate at some point.
We define a simple InvariantsTracker class which monitors the recursion
for us and ensures that it terminates. InvariantsTracker just keeps a list
of object instances that it has already seen. We pass a new
InvariantsTracker to the first checkInvariants(..) call which in turn
passes the same instance to recursive calls.

boolean checkInvariants(InvariantsTracker hitList)
{
	 if (hitList.alreadyHit(this)) return false;

	 Assert.invariant(d_top < d_size);

	 return true;
} // checkInvariants(..)

In a subclass, the form is slightly different, since the base class
performs the check:

boolean checkInvariants(InvariantsTracker hitList)
{
	 if (!(super.checkInvariants(hitList))) return false;

	 // ...

	 return true;
} // checkInvariants(..)

The test code then looks like this:

void testPop() throws Exception
{
	 d_stack.push(item1);
	 d_stack.checkInvariants(new InvariantsTracker());

	 // ...
} // testPop()

This ends up being a very simple and powerful technique. Having the unit
tests run the consistency checks in addition to checking external logic
allows you to catch many more errors with far fewer tests. You begin to
catch errors early on that don't normally show up until load or soak
testing and are much harder to diagnose then. Our code is available for
download if you are interested. There is also a package out
there called iContract which generates invariant checking code based on
special javadoc comments. iContract has the advantage that the invariants,
preconditions, and postconditions are clearly specified in your docs, but
its disadvantage is that it is a preprocessor.

On Tue, 6 Nov 2001 john_naylor@... wrote:

> i have been assigned the task of pushing our development team toward
> unit testing.  i have been working with junit for a few weeks now but
> continue to struggle with one issue.  it seems to me there is tension
> between unit testing and my preferred api.  for a given class i would
> like to expose only a handful of methods, yet do not want to forfeit
> testing my private methods.  my feeling is that i should be concerned
> with continually testing those methods, and yet fail to see why i
> should expose methods which are meaningless outside the "blackbox".
>
> perhaps i am missing something obvious about good design.  in the
> mean time i have set up a simple interface which classes i test
> internally must implement.
>
> public interface Testable
> {
>  public static final boolean INTERNAL_MODE = true;
>
>  public void runInternalTests() throws Exception;
> }
>
> this allows me to run internal tests and handle assertions by calling
> the static methods of Assert.  INTERNAL_MODE must be checked within
> runInternalTests().  This allows internal testing to be turned off
> for production builds.
>
> any insight about this dilemna would be appreciated.
>
>
>
>
> 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

Actually, it *can* break, depending on your naming conventions.

public class Broken {
     private String message;
     public Broken(String message) {
         message = message;
     }
     public String getMessage() { return message; }
     public void setMessage() { message = message; }
}

This class is broken, but this simple test would expose the bug.

public class BrokenTestCase extends TestCase {
     public BrokenTestCase(String name) { super(name); }
     public void testCreate() {
         Broken b = new Broken("Hello");
         assertEquals("Hello", b.getMessage());
         b.setMessage("Hello2");
         assertEquals("Hello2", b.getMessage());
     }
}

Now you will likely write, "I would never make that mistake." You might, if
you do a global search-and-replace on your code and the end result is the
code above. I leave it as an exercise to the reader to imagine how that
could happen. HINT: It happened to me. :)

My suggestions:

1. Use the immutable object idiom. (No setX() methods. If you need a new
value, make a new object.)
2. Write a simple test to ensure that what you pass to the constructor is
what the getX() methods answer.

Do this until you start writing perfect code all the time. :)

JBR.

----- Begin original message -----
How about a class that can't possibly break?  Say a class with only setters
and getters?



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

One of Brian Marick's key points in his book is that people don't make
complex mistakes. It's the simple things that are most likely to go wrong:
cut and paste errors, bad search and replace, off-by-one in a conditional
or loop, bas parenthesization, etc. If you look for the simple errors, you
catch them before they become complex problems.

On Tue, 6 Nov 2001, J. B. Rainsberger wrote:

> Actually, it *can* break, depending on your naming conventions.
>
> public class Broken {
>     private String message;
>     public Broken(String message) {
>         message = message;
>     }
>     public String getMessage() { return message; }
>     public void setMessage() { message = message; }
> }
>
> This class is broken, but this simple test would expose the bug.
>
> public class BrokenTestCase extends TestCase {
>     public BrokenTestCase(String name) { super(name); }
>     public void testCreate() {
>         Broken b = new Broken("Hello");
>         assertEquals("Hello", b.getMessage());
>         b.setMessage("Hello2");
>         assertEquals("Hello2", b.getMessage());
>     }
> }
>
> Now you will likely write, "I would never make that mistake." You might, if
> you do a global search-and-replace on your code and the end result is the
> code above. I leave it as an exercise to the reader to imagine how that
> could happen. HINT: It happened to me. :)
>
> My suggestions:
>
> 1. Use the immutable object idiom. (No setX() methods. If you need a new
> value, make a new object.)
> 2. Write a simple test to ensure that what you pass to the constructor is
> what the getX() methods answer.
>
> Do this until you start writing perfect code all the time. :)
>
> JBR.
>
> ----- Begin original message -----
> How about a class that can't possibly break?  Say a class with only setters
> and getters?
>
>
>
> _________________________________________________________________
> 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/
>
>
>

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

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

Actually, it doesn't matter much for me to argue the possibilities of
break.  After spending time on building mock objects, controllers and
setting up environment, I am just more than happy to spend one more
minute to test those setters and getters.  It really puts my mind on
ease knowing that I have a good test coverage instead of reminding
myself every time "You don't have test for the setters and getters
because they are too simple to test".

And yes, I did make mistake once on a setter and the test code caught
it.  (In case you wonder, I mistyped the name of the field variable and
the code insight found another one for me. :)  )

Shane

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

J. B. Rainsberger wrote:

>Actually, it *can* break, depending on your naming conventions.
>
>public class Broken {
>    private String message;
>    public Broken(String message) {
>        message = message;
>    }
>    public String getMessage() { return message; }
>    public void setMessage() { message = message; }
>}
>
>This class is broken, but this simple test would expose the bug.
>
>public class BrokenTestCase extends TestCase {
>    public BrokenTestCase(String name) { super(name); }
>    public void testCreate() {
>        Broken b = new Broken("Hello");
>        assertEquals("Hello", b.getMessage());
>        b.setMessage("Hello2");
>        assertEquals("Hello2", b.getMessage());
>    }
>}
>
>Now you will likely write, "I would never make that mistake." You might, if
>you do a global search-and-replace on your code and the end result is the
>code above. I leave it as an exercise to the reader to imagine how that
>could happen. HINT: It happened to me. :)
>
>My suggestions:
>
>1. Use the immutable object idiom. (No setX() methods. If you need a new
>value, make a new object.)
>2. Write a simple test to ensure that what you pass to the constructor is
>what the getX() methods answer.
>
>Do this until you start writing perfect code all the time. :)
>
>JBR.
>
>----- Begin original message -----
>How about a class that can't possibly break?  Say a class with only setters
>and getters?
>
>
>
>_________________________________________________________________
>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/
>
>