I think I have read somewhere that this is not guaranteed, it is just a result
of the current implementation. Is this really guaranteed?

/Håkan

> -----Original Message-----
> From: rainsber@... [mailto:rainsber@...]
> Sent: Monday, July 09, 2001 4:35 PM
> To: junit@yahoogroups.com
> Subject: Re: [junit] method dependency
>
>
...
>
> Failing that, override method suite() for the test and put
> the tests in the
> appropriate order.
>
> public class MyTestCase ... {
>     public static Test suite() {
>         TestSuite result = new TestSuite();
>         result.addTest(new MyTestCase("testA"));
>         result.addTest(new MyTestCase("testB"));
>         result.addTest(new MyTestCase("testC"));
>         ...
>         return result;
>     }
> }
>
> This guarantees the order in which the tests are executed
> within the suite.
>
> J. B. Rainsberger  <rainsber@...>
> Commerce Suite Accelerator: Rule Services, IBM Toronto Lab
> 8200 Warden Av, Office A3-735 [A3/FNB/8200/MKM]
> Markham ON   L6G 1C7
> 905 413-2501 (969-2501)
>
>
> "Clemmons, Scott" <scott.clemmons@...> on
> 07/09/2001 09:06:44
>
> Please respond to junit@yahoogroups.com
>
> To:   JUnit <junit@yahoogroups.com>
> cc:
> Subject:  [junit] method dependency
>
>
>
> Hi,
>
> In my class, I have methods A(),B(), C(), where A() must be
> called before B
> (), B() before C(). I have individual test cases for each
> method. In order
> to run the tests in the specified order, I must arrange the
> actual methods
> in the appropriate order. I know this is not a good thing, so how do I
> avoid it? I really hate to lump them into one testcase.
>
> Thanks,
>
>
> Scott
> :-> Change is inevitable except from vending machines.
>
>
> 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/
>
>

JDepend 2.0 is now available with the following new features:

Version: 2.0
Date: 08.01.01
Description: Support class file parsing
Changes:

- Added support for parsing class files in addition to source files.
Class file parsing is more accurate in its ability to identify
referenced packages not directly visible from 'package' or 'import'
statements.  Analyzed package references include super classes,
implemented interfaces, class variables, method return types, method
parameter types, method exception types, and method local variable
types.  If a given directory contains both a source file and a class
file for the same Java class, then the class file is analyzed and the
source file is ignored.  For this release, class files must exist in a
directory; JAR files are not supported.

The JDepend documentation is available at

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

JDepend 2.0 can be downloaded directly from

        http://www.clarkware.com/software/jdepend2.0.zip


Any feedback you may have is most welcome and appreciated.

Thanks and enjoy!

Mike

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

I've started a Distributed JUnit project on sourceforge
http://sourceforge.net/projects/djunit/ , but have not had any time
to write the code. Perhaps members of this list will be interested in
joining the project. Please read the DOCS section for a detailed
description.

Regards,

David

--- In junit@y..., route_m69@y... wrote:
> Hi,
>
> I have 7 test, and i want to run each of them in a separate VM. Is
> there a way?
>
> Thanks
>
> Here is my test suite ->
>
> package common.clock.test;
>
> import junit.framework.*;
>
> public class Test_ClockSuite {
>  public static void main (String[] args) {
> 	 junit.textui.TestRunner.run (suite());
>
>  }
>  public static Test suite ( ) {
>          TestSuite suite= new TestSuite();
>          suite.addTest(new Test_StandardClock_1("test"));
>          suite.addTest(new Test_StandardClock_2("test_2"));
>          suite.addTest(new Test_StandardClock_3("test3"));
>
>          suite.addTest(new Test_FixedClock_1("test_1"));
>          suite.addTest(new Test_FixedClock_2("test_2"));
>
>          suite.addTest(new Test_OffsetClock_1("test_1"));
>          suite.addTest(new Test_OffsetClock_2("test_2"));
>
> 	 return suite;
>  }
>
> }

I though I sent this before but I guess not.

Can anyone offer any pointers on how to write xuint tests for ui code?

Thanks
/b

--- In junit@y..., "Clemmons, Scott" <scott.clemmons@f...> wrote:
> Hi,
>
> In my class, I have methods A(),B(), C(), where A() must be called
before B(), B() before C(). I have individual test cases for each
method. In order to run the tests in the specified order, I must
arrange the actual methods in the appropriate order. I know this is
not a good thing, so how do I avoid it? I really hate to lump them
into one testcase.

Either lump them into one test case or break the dependency. If you
just muddle through, you're missing a chance for a design insight.

Kent

hi all
        Their are some problems in junit which are as
follows

1) when we write a test case for a method i write 2
cases that is success and failure...
    suppose their is a method which throws 3 exceptions
. should i give all the exception's for
    success

    for ex:-
	 originall method
       public int xxx(int c, int d)
	 {
	 }

	 we assume that above method throws 3 exceptions a,b,c



	 for success how should i write
	 i am following the this procedure

	 // success
	 public int testxxx()
	 {
		 try
		 {
		 }
		 catch(aException aex)
		 {}
		 catch(bException bex)
		 {}
		 catch(cException cex)
		 {}
	 }
	 for failure i am following procedure
	 i am assuming that when i give wrong parameters it
should throw "a exception"

	 // failure
	 public int testxxx()
	 {
		 try
		 {
			 code
			 fail()
		 }
		 catch(aException aex)
		 {}
		 catch(bException bex)
		 {
			 fail();
		 }
		 catch(cException cex)
		 {
			 fail();
		 }
	 }
	 (or) i shall do this process

	 // failure
	 public int testxxx()
	 {
		 try
		 {
			 code
			 fail()
		 }
		 catch(aException aex)
		 {}
		 catch(Exception e)
		 {
			 fail();
		 }

	 }
regards Bhanu


__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

There has been a long discussion about this topic with pros and cons during the
last month. There is also a third alternative in which you let the framework
take care of all the unexpected exceptions. The code is easier to write but not
as informative:

	 // success
	 public int testxxx throws Exception()
	 {
		 code
	 }

	 // failure
	 public int testxxx throws Exception()
	 {
		 try
		 {
			 code
			 fail()
		 }
		 catch(aException aex)
		 {}
	 }

/Håkan

> -----Original Message-----
> From: bhanu prakash [mailto:bhanu_sistla@...]
> Sent: Thursday, August 02, 2001 7:33 AM
> To: junit@yahoogroups.com
> Subject: [junit] About Testing the Exception
>
>
>
> hi all
>        Their are some problems in junit which are as
> follows
>
> 1) when we write a test case for a method i write 2
> cases that is success and failure...
>    suppose their is a method which throws 3 exceptions
> . should i give all the exception's for
>    success
>
>    for ex:-
>  originall method
>       public int xxx(int c, int d)
>  {
>  }
>
>  we assume that above method throws 3 exceptions a,b,c
>
>
>
>  for success how should i write
>  i am following the this procedure
>
>  // success
>  public int testxxx()
>  {
> 	 try
> 	 {
> 	 }
> 	 catch(aException aex)
> 	 {}
> 	 catch(bException bex)
> 	 {}
> 	 catch(cException cex)
> 	 {}
>  }
>  for failure i am following procedure
>  i am assuming that when i give wrong parameters it
> should throw "a exception"
>
>  // failure
>  public int testxxx()
>  {
> 	 try
> 	 {
> 		 code
> 		 fail()
> 	 }
> 	 catch(aException aex)
> 	 {}
> 	 catch(bException bex)
> 	 {
> 		 fail();
> 	 }
> 	 catch(cException cex)
> 	 {
> 		 fail();
> 	 }
>  }
>  (or) i shall do this process
>
>  // failure
>  public int testxxx()
>  {
> 	 try
> 	 {
> 		 code
> 		 fail()
> 	 }
> 	 catch(aException aex)
> 	 {}
> 	 catch(Exception e)
> 	 {
> 		 fail();
> 	 }
>
>  }
> regards Bhanu
>
>
> __________________________________________________
> Do You Yahoo!?
> Make international calls for as low as $.04/minute with
> Yahoo! Messenger
> http://phonecard.yahoo.com/
>
> ------------------------ Yahoo! Groups Sponsor
> ---------------------~-->
> Small business owners...
> Tell us what you think!
> http://us.click.yahoo.com/vO1FAB/txzCAA/ySSFAA/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/
>
>

I suppose, one could write an assertThrows to be passed a method object

e.g

void assertThrows( Method method, Object object, Object[] parameters, Class
expectedExceptionClass ) throws Exception
{
    try
    {
       method.invoke( object, parameters );
       fail("Expecting exception of class " + exceptionClass.getName());
    }
    catch( Exception actualException )
    {
       if( !expectedExceptionClass.isAssignableFrom( actualException ) )
          throw actualException;  // or fail or whatever
    }
}

Alternatively, one could use a block object
(http://c2.com/cgi/wiki?BlocksInJava)
e.g.
void assertThrows( Function function, Class expectedExceptionClass ) throws
Exception

where Function is implemented by an annonymous inner class.

--
Neil Swingler

> -----Original Message-----
> From: Hkan Danielsson (ERA) [mailto:hakan.danielsson@...]
> Sent: 02 August 2001 07:23
> To: 'junit@yahoogroups.com'
> Subject: RE: [junit] About Testing the Exception
>
>
> There has been a long discussion about this topic with pros and
> cons during the last month. There is also a third alternative in
> which you let the framework take care of all the unexpected
> exceptions. The code is easier to write but not as informative:
>
>  // success
>  public int testxxx throws Exception()
>  {
> 	 code
>  }
>
>  // failure
>  public int testxxx throws Exception()
>  {
> 	 try
> 	 {
> 		 code
> 		 fail()
> 	 }
> 	 catch(aException aex)
> 	 {}
>  }
>
> /Hkan
>
> > -----Original Message-----
> > From: bhanu prakash [mailto:bhanu_sistla@...]
> > Sent: Thursday, August 02, 2001 7:33 AM
> > To: junit@yahoogroups.com
> > Subject: [junit] About Testing the Exception
> >
> >
> >
> > hi all
> >        Their are some problems in junit which are as
> > follows
> >
> > 1) when we write a test case for a method i write 2
> > cases that is success and failure...
> >    suppose their is a method which throws 3 exceptions
> > . should i give all the exception's for
> >    success
> >
> >    for ex:-
> >  originall method
> >       public int xxx(int c, int d)
> >  {
> >  }
> >
> >  we assume that above method throws 3 exceptions a,b,c
> >
> >
> >
> >  for success how should i write
> >  i am following the this procedure
> >
> >  // success
> >  public int testxxx()
> >  {
> > 	 try
> > 	 {
> > 	 }
> > 	 catch(aException aex)
> > 	 {}
> > 	 catch(bException bex)
> > 	 {}
> > 	 catch(cException cex)
> > 	 {}
> >  }
> >  for failure i am following procedure
> >  i am assuming that when i give wrong parameters it
> > should throw "a exception"
> >
> >  // failure
> >  public int testxxx()
> >  {
> > 	 try
> > 	 {
> > 		 code
> > 		 fail()
> > 	 }
> > 	 catch(aException aex)
> > 	 {}
> > 	 catch(bException bex)
> > 	 {
> > 		 fail();
> > 	 }
> > 	 catch(cException cex)
> > 	 {
> > 		 fail();
> > 	 }
> >  }
> >  (or) i shall do this process
> >
> >  // failure
> >  public int testxxx()
> >  {
> > 	 try
> > 	 {
> > 		 code
> > 		 fail()
> > 	 }
> > 	 catch(aException aex)
> > 	 {}
> > 	 catch(Exception e)
> > 	 {
> > 		 fail();
> > 	 }
> >
> >  }
> > regards Bhanu
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Make international calls for as low as $.04/minute with
> > Yahoo! Messenger
> > http://phonecard.yahoo.com/
> >
> > ------------------------ Yahoo! Groups Sponsor
> > ---------------------~-->
> > Small business owners...
> > Tell us what you think!
> > http://us.click.yahoo.com/vO1FAB/txzCAA/ySSFAA/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/
>
>

Hi,

I don't know if it can be implemented with Swing,
but I think the swingui TestRunner misses a [stay on top] option.

I like the feel good effect of the green bar,
but having first, constantly, to call back its window from under my IDE makes me
prefer the textui.TestRunner.

I'd like to see the Green Bar again.


Alain Ravet


This mail has been checked by exiscan.
To be safe, please scan the mail attachements with your local virus scanner !

If I wanted to pass some configuration information to a TestCase through
command line
arguments, is there a way to do this using the JUnit framework. Currently, I
am hardcoding this info in the test case.
I am OK with hardcoding some test data but would prefer to pass in
conectivity information through the command line
as I can then run the test on different development environments without
having to recompile.
Any help is appreciated

Thanks
Anand Narayan
Juniper Bank





_______________________________________________________

Juniper Bank
"Rated #1 in Customer Confidence"
Gomez Inc., Summer 2001 Internet Credit Card Scorecard
www.juniper.com
_______________________________________________________

This e-mail and any files transmitted with it may contain confidential
and/or proprietary information. It is intended solely for the use of the
individual or entity who is the intended recipient. Unauthorized use of this
information is prohibited. If you have received this in error, please
contact the sender by replying to this message and delete this material from
any system it may be on.

What about using a properties file?

"Narayan, Anand" wrote:

> If I wanted to pass some configuration information to a TestCase through
> command line
> arguments, is there a way to do this using the JUnit framework. Currently, I
> am hardcoding this info in the test case.
> I am OK with hardcoding some test data but would prefer to pass in
> conectivity information through the command line
> as I can then run the test on different development environments without
> having to recompile.
> Any help is appreciated
>
> Thanks
> Anand Narayan
> Juniper Bank
>
> _______________________________________________________
>
> Juniper Bank
> "Rated #1 in Customer Confidence"
> Gomez Inc., Summer 2001 Internet Credit Card Scorecard
> www.juniper.com
> _______________________________________________________
>
> This e-mail and any files transmitted with it may contain confidential
> and/or proprietary information. It is intended solely for the use of the
> individual or entity who is the intended recipient. Unauthorized use of this
> information is prohibited. If you have received this in error, please
> contact the sender by replying to this message and delete this material from
> any system it may be on.
>
>
> 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/

Or just having the properties on the command line ("-D option").

-Jason

     > -----Original Message-----
     > From: Thomas Obst [mailto:thomas_obst@...]
     > Sent: Thursday, August 02, 2001 10:08 AM
     > To: junit@yahoogroups.com
     > Subject: Re: [junit] Command line arguments
     >
     >
     > What about using a properties file?
     >
     > "Narayan, Anand" wrote:
     >
     > > If I wanted to pass some configuration information to a
     > TestCase through
     > > command line
     > > arguments, is there a way to do this using the JUnit
     > framework. Currently, I
     > > am hardcoding this info in the test case.
     > > I am OK with hardcoding some test data but would prefer
     > to pass in
     > > conectivity information through the command line
     > > as I can then run the test on different development
     > environments without
     > > having to recompile.
     > > Any help is appreciated
     > >
     > > Thanks
     > > Anand Narayan
     > > Juniper Bank
     > >
     > > _______________________________________________________
     > >
     > > Juniper Bank
     > > "Rated #1 in Customer Confidence"
     > > Gomez Inc., Summer 2001 Internet Credit Card Scorecard
     > > www.juniper.com
     > > _______________________________________________________
     > >
     > > This e-mail and any files transmitted with it may
     > contain confidential
     > > and/or proprietary information. It is intended solely
     > for the use of the
     > > individual or entity who is the intended recipient.
     > Unauthorized use of this
     > > information is prohibited. If you have received this in
     > error, please
     > > contact the sender by replying to this message and
     > delete this material from
     > > any system it may be on.
     > >
     > >
     > > 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/

>I disagree. Wouldn't method validate(DataObject) have to either return a
>boolean or perform the assertion itself?

Not at all. The method is designed as "validate this thing, if ok, let it
pass, if not throw a ValidationException).
You can find tons of method like that in the real world.
(for example, :
http://java.sun.com/products/jdk/1.2/docs/api/java/security/AccessController
.html#checkPermission(java.security.Permission)  )

>Of course, I assume that you prefer not to have an unsuccessful validation
>register as an error.

Why not? Your code below lacks the stack trace for debugging (A
fail(Throwable) would probably be usefull here). Letting the error go all
the way up to the junit framework let me write even simpler tests. To me,
it's the simplet thing that could work. I don't think it makes them hard to
read, I got used pretty fast to the fact that if something throws inside a
test, the test will fail. I know other people on this list also work that
way. This enable me to spend less time writing tests, and more time focusing
on what counts : what should I test and how to implement it. I don't like
writing asssertTrue(true) or lines like that, because I think they will
confuse the person who reads the code, like somebody else said. My tests are
always very simple: a couple of lines. Only basic understanding of how junit
works is needed in order to understand them. Yes, a validation error will
show as an error and not a failure in the runner. I personnaly don't make
any difference between those 2. The unit test passed or it busted. If it's
an error, it just indicates to me that an exception was thrown (other than
AssertionFailedError) from the test method.

>try {
>    validate();
>}
>catch (ValidationException oops) {
>    fail(oops.toString());
>}
>Remember, folks: fail() is an assertion! Look at the code.

Of course it does!:)
I agree with Robert saying :
"So, code that dyamically counts assertions will count the above as having
no assertions if it passes."

This would then be a "false warning". Unless you are talking about static
anaylis which I doubt. Please correct me if this is the case.

I guess we just have a slightly different way of writing tests. Writing
compact tests look like obsfucation to some people while putting lot of
details can look like... obsfucation to some other.  :)

mathieu
----- Original Message -----
From: J. B. Rainsberger
To: junit@yahoogroups.com
Sent: Saturday, July 28, 2001 11:49 AM
Subject: [junit] False warnings? (Re: re - assert counting)


>re - assert countingFrom: Keith Ray
> >As I said before, I would just want a warning when a test method is empty
>or has no asserts...
> > but I don't want to go to the trouble of getting some code-coverage tool
>working.
>
>Interesting. But in my case I would have a lot of "false warnings" because
>I
>have a lot of methods that validate something and throw if it's invalid
>(but
>do nothing if valid, so return is void). The tests look like that :
>
>public void testAValidationTest() throws Exception {
>     validator.validate(VALID_DATA);
>}
>
>So, no asserts, but a perfectly valid test case.

I disagree. Wouldn't method validate(DataObject) have to either return a
boolean or perform the assertion itself? In the first case, you'd have to
write assertTrue(validator.validate()), or otherwise the assertTrue() would
be inside the method validate(). Either way, you're performing at least one
assert.

Of course, I assume that you prefer not to have an unsuccessful validation
register as an error. In the last case, you'd write

try {
     validate();
}
catch (ValidationException oops) {
     fail(oops.toString());
}

Remember, folks: fail() is an assertion! Look at the code.

JBR.

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


Yahoo! Groups Sponsor
ADVERTISEMENT




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 encountered an interesting problem with JUnit
3.7.  When the tested code runs into a call to the
reflection method 'isAssignableFrom()' Class method,
using the textui, all works great.  But when the
swingui is used, the 'isAssignableFrom()' method
always returns false.  Has anyone else encountered a
problem like this.  We are using JVM 1.3.1 running on
Win2000 machines.

Thanks in advance..

Mark Johnson



=====

Mark


__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

I've encountered a similar problem with using JNDI to look up EJBs from a
JUnit TestCase.
In this case using the swingui or ui causes a ClassCastException when
narrowing a reference to
the home object.
Using the textui it works fine.

Anyone know of any issues with the other types of ui TestRunner(s).

Thanks
Anand Narayan

-----Original Message-----
From: Mark Johnson [mailto:mfjohnson98@...]
Sent: Thursday, August 02, 2001 2:20 PM
To: junit@yahoogroups.com
Subject: [junit] isAssignableFrom problem using Swing


I have encountered an interesting problem with JUnit
3.7.  When the tested code runs into a call to the
reflection method 'isAssignableFrom()' Class method,
using the textui, all works great.  But when the
swingui is used, the 'isAssignableFrom()' method
always returns false.  Has anyone else encountered a
problem like this.  We are using JVM 1.3.1 running on
Win2000 machines.

Thanks in advance..

Mark Johnson



=====

Mark


__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.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/



_______________________________________________________

Juniper Bank
"Rated #1 in Customer Confidence"
Gomez Inc., Summer 2001 Internet Credit Card Scorecard
www.juniper.com
_______________________________________________________

This e-mail and any files transmitted with it may contain confidential
and/or proprietary information. It is intended solely for the use of the
individual or entity who is the intended recipient. Unauthorized use of this
information is prohibited. If you have received this in error, please
contact the sender by replying to this message and delete this material from
any system it may be on.

This smells like one of the class loader issue.

Probably you can try to put the class that you are testing into the excluding
list in the property file.


Mark Johnson wrote:

> I have encountered an interesting problem with JUnit
> 3.7.  When the tested code runs into a call to the
> reflection method 'isAssignableFrom()' Class method,
> using the textui, all works great.  But when the
> swingui is used, the 'isAssignableFrom()' method
> always returns false.  Has anyone else encountered a
> problem like this.  We are using JVM 1.3.1 running on
> Win2000 machines.
>
> Thanks in advance..
>
> Mark Johnson
>
> =====
>
> Mark
>
> __________________________________________________
> Do You Yahoo!?
> Make international calls for as low as $.04/minute with Yahoo! Messenger
> http://phonecard.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/

Sometimes, not always, when I first invoke the Swing TestRunner, I get a
discrepancy
in the displayed "Runs:" value.  It appears as if some events may be getting
lost, as
the final value may show something like 10/31 after all the tests have run.
Rerunning
the tests will display the proper 31/31.  In fact, I just discovered that
alt-tabbing to
another window and then alt-tabbing back will correct the display, so
perhaps it's
just a Swing display refresh bug.

It's no big deal, but I mention it in case it causes confusion for others,
too.

  - George

  ----------------------------------------------------------------
  George Dinwiddie                Arbitron, Information Technology
  9705 Patuxent Woods Drive                Columbia, MD 21046-1572
  voice: 410-312-8379                         fax: 410-312-8614
  George.Dinwiddie@...           http://www.arbitron.com/
  ----------------------------------------------------------------
  The gods do not deduct from man's alloted span those hours spent
  in sailing.                             http://www.Alberg30.org/
  ----------------------------------------------------------------

Anand Narayan
(302) 255-8027




_______________________________________________________

Juniper Bank
"Rated #1 in Customer Confidence"
Gomez Inc., Summer 2001 Internet Credit Card Scorecard
www.juniper.com
_______________________________________________________

This e-mail and any files transmitted with it may contain confidential
and/or proprietary information. It is intended solely for the use of the
individual or entity who is the intended recipient. Unauthorized use of this
information is prohibited. If you have received this in error, please
contact the sender by replying to this message and delete this material from
any system it may be on.

> >I disagree. Wouldn't method validate(DataObject) have to either return a
> >boolean or perform the assertion itself?
>
>Not at all. The method is designed as "validate this thing, if ok, let it
>pass, if not throw a ValidationException).

Certainly a fine design. I don't know why I didn't think of that at the
time, but...

> >Of course, I assume that you prefer not to have an unsuccessful
>validation
> >register as an error.
>
>Why not? Your code below lacks the stack trace for debugging (A
>fail(Throwable) would probably be usefull here). Letting the error go all
>the way up to the junit framework let me write even simpler tests.

Agreed; however, I find it nice to go on the assumption that a failure means
my code is broken and an error means my test is broken. I wonder if not many
people find this useful or if I'm overstating how useful it can be.

>Yes, a validation error will
>show as an error and not a failure in the runner. I personnaly don't make
>any difference between those 2. The unit test passed or it busted. If it's
>an error, it just indicates to me that an exception was thrown (other than
>AssertionFailedError) from the test method.

If that works for you, then certainly you're in good shape. You are doing
something simple, and until there's a reason to become more complex, why
bother? That's the attitude. :)

>I guess we just have a slightly different way of writing tests. Writing
>compact tests look like obsfucation to some people while putting lot of
>details can look like... obsfucation to some other.  :)

As long as the test communicates, it doesn't really matter how it
communicates. Of course, it must communicate *well*.

JBR.


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

>Agreed; however, I find it nice to go on the assumption that a failure
means
>my code is broken and an error means my test is broken. I wonder if not
many
>people find this useful or if I'm overstating how useful it can be.

Interesting comment. What if the tested code throw a NullPointerException?
You catch it and fail()? So All your tests contain try ..catch stuf...around
tested method but not around asserts?

mathieu

----- Original Message -----
From: J. B. Rainsberger
To: junit@yahoogroups.com
Sent: Friday, August 03, 2001 3:42 PM
Subject: [junit] Re: False warnings? (Re: re - assert counting)


> >I disagree. Wouldn't method validate(DataObject) have to either return a
> >boolean or perform the assertion itself?
>
>Not at all. The method is designed as "validate this thing, if ok, let it
>pass, if not throw a ValidationException).

Certainly a fine design. I don't know why I didn't think of that at the
time, but...

> >Of course, I assume that you prefer not to have an unsuccessful
>validation
> >register as an error.
>
>Why not? Your code below lacks the stack trace for debugging (A
>fail(Throwable) would probably be usefull here). Letting the error go all
>the way up to the junit framework let me write even simpler tests.

Agreed; however, I find it nice to go on the assumption that a failure means
my code is broken and an error means my test is broken. I wonder if not many
people find this useful or if I'm overstating how useful it can be.

>Yes, a validation error will
>show as an error and not a failure in the runner. I personnaly don't make
>any difference between those 2. The unit test passed or it busted. If it's
>an error, it just indicates to me that an exception was thrown (other than
>AssertionFailedError) from the test method.

If that works for you, then certainly you're in good shape. You are doing
something simple, and until there's a reason to become more complex, why
bother? That's the attitude. :)

>I guess we just have a slightly different way of writing tests. Writing
>compact tests look like obsfucation to some people while putting lot of
>details can look like... obsfucation to some other.  :)

As long as the test communicates, it doesn't really matter how it
communicates. Of course, it must communicate *well*.

JBR.

--- Mathieu Gervais <egoine_@...> wrote:
> Interesting comment. What if the tested code throw a
> NullPointerException?
> You catch it and fail()?

Usually, I'd let that go as an Error. It's an ambiguous case because
the method under test could be throwing that because of bad arguments
or because of a bug in the method under test.

I go back and forth on the Failure vs. Error thing, but it sure has
helped to make the distinction as often as it's easy. When I see a lot
of Errors (and few or no Failures), the first thing I look for is build
or test misconfiguration. If I see many Failures and few (or no)
Errors, I look for a core or major change to the software. The first
scernario seems to happen a lot when using JBuilder 4 (which under our
configuration, which clearly must be wrong, seems to not always make
everything it should even when we do a "rebuild"). The second
occasionally happens when integrating bug fixes or "minor" upgrades to
the core of our product (even after it passed its own unit tests).

Regards,

Rob


__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

> Agreed; however, I find it nice to go on the
> assumption that a failure means
> my code is broken and an error means my test is
> broken. I wonder if not many
> people find this useful or if I'm overstating how
> useful it can be.

In the past I tried to make this same distinction, but
I found in practice that it was often arbitrary.
Often, I'll change code that invalidates existing test
cases so they start throwing assertions. The code
isn't broken, the problem is that the test cases are
out of sync with the code since the assumptions have
changed. To me, it doesn't really matter what's broken
(testing code or tested code) or how I'm notified of
the problem (assertion or error). The point is that I
need to investigate the problem and fix it.

For me, the path of least resistance is the most
effective: make my test cases simple to write and
simple to understand. Thus, I prefer letting JUnit
handle uncaught exceptions as errors since this:

   public void testFoo() throws Exception {
     code;
   }

is simpler than:

   public void testFoo() {
     try {
       code;
     catch (ErrorException e) {
       fail(...);
     }
   }

Both versions say the same thing to me: I expect
"code" to work, and if it doesn't something is wrong.
I just find the latter case less clear.

My two cents...



__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

> >Agreed; however, I find it nice to go on the assumption that a failure
> means
> >my code is broken and an error means my test is broken. I wonder if not
> many
> >people find this useful or if I'm overstating how useful it can be.
>
> Interesting comment. What if the tested code throw a NullPointerException?
> You catch it and fail()? So All your tests contain try ..catch
stuf...around
> tested method but not around asserts?

I'm not sure I understand your last comment, so let me try to address your
question.

"What if the tested code throws a NullPointerException?" There are two
possibilities: I expect the exception or I do not. If I expect the
exception, then I have a test that runs like this:

public void testA() {
     try {
         doSomething();
         fail("How did I get here?!");
     }
     catch (NullPointerException success) {}
}

We've already talked for a long time about this coding pattern on this
mailing list, so I state it "without proof" as a best practice.

If I do not expect the exception, then either my test or my code is broken.
Since I don't want to debug, what I generally do is add a bunch of
assertNotNull() statements into my tests to determine which reference is
null. Once I determine which reference is null, it is generally easy to
determine whether the test or the code is broken. Specifically, I generally
put stronger "not null" preconditions on the test to quickly rule out that
the test is broken. Also, it depends when I get the NullPointerException:
what did I just write? the test or code? Usually that tells me.

Can you clarify what you meant by your last statement? Why would I put
try/catch around an assertion?

Thanks.

JBR.

I have to test the following java handler

public class DailyListingSplitHandler extends StatsHandler {

     private Connection conn;
     private CallableStatement cstmt;
     private Statement stmt;
     private ResultSet rs;
     private String procCallStmt;
     private String temp;
     private String temp1;
     private String temp2;
     private int len;
     private int len1;

     private String next;


   final static String className = DailyListingSplitHandler.class.getName();
   final static Category CAT = Category.getInstance(className);
   final static Category DB = Category.getInstance(className+".DB");


     private String dateString;

     public DailyListingSplitHandler (String next,
                                           HttpServletRequest request,
                                           HttpServletResponse response,
                                           ServletContext context,
                                           DatabaseObject dbobj) {
         super (request, response, context, dbobj);
         this.next = next;
     }

     public String processRequest() throws
                 ServletException, IOException {
             //-------CAT.info("request from ip: "+request.getRemoteAddr());
             try {
                 conn = databaseObj.getConnection();
             } catch (Exception se) {
                 DB.error("failed to get connection", se);
             }

             try
             {
                 SimpleDateFormat simpleDateFormat = new
SimpleDateFormat("yyyy-MM-dd");
                 java.util.Date date= new java.util.Date();
                 String dateString = simpleDateFormat.format(date);


                 com.nqb.ps.otcstats.HandlerSearchResultBean dailyResultBean
=
                                     new
com.nqb.ps.otcstats.HandlerSearchResultBean();
                 GregorianCalendar cal = new GregorianCalendar();
                 cal.setTime(new java.util.Date());
                 cal.roll(Calendar.DAY_OF_YEAR, -7);
                 java.util.Date fromDate = cal.getTime();
                 String fromdate = simpleDateFormat.format(fromDate);

                 procCallStmt = "{call history_by_date(?,?,?)}";
                 DB.info("call
history_by_date("+dateString+","+dateString+",L)");
                 try {
                 cstmt = conn.prepareCall(procCallStmt);
                 cstmt.setString(1, fromdate);
                 cstmt.setString(2, dateString);
                 cstmt.setString(3,"L");
                     rs = cstmt.executeQuery();
                 } catch(SQLException sqle) {
                     DB.error("Failed to execute query", sqle);
                     next = Links.ERROR_PAGE;
                 } catch(Exception e) {
                     DB.error("general Exception while executing the query",
e);
                     next = Links.ERROR_PAGE;
                 }


                while(rs.next())

                 {
                     temp = (rs.getString(18) == null ||
rs.getString(18).trim().equals("")) ? "N/A" :
(rs.getString(18).startsWith("3")?
rs.getString(18).substring(1):rs.getString(18));
                     temp = temp.trim();
                     len = temp.length();
                     len1 = 0;
                     while(!(temp.charAt(len1)==';')&&(len1 < len-1))
                     {
                         len1++;
                     }

                     if(len1+1 == len)
                     temp = (rs.getString(18) == null ||
rs.getString(18).trim().equals("")) ? "N/A" :
(rs.getString(18).startsWith("3")?
rs.getString(18).substring(1):rs.getString(18));
                     else
                     temp = temp.substring(0,len1);

                     String comp = rs.getString(16).trim();
                     if(comp.equals("Unknown
Company")||comp.equals("Unmatched Company")||comp.equals("")||comp==null)
                         comp = rs.getString(17);


                     CAT.debug("creating bean HandlerSearchResultBeanRow
using parameters: null, "+
                                 rs.getString(1)+
                                 ","+
                                 ((rs.getString(3) == null ||
rs.getString(3).trim().equals("")) ? "N/A" :
(rs.getString(3).startsWith("3")?
rs.getString(3).substring(1):rs.getString(3)))+
                                 ","+
                                 ((rs.getString(4) == null ||
rs.getString(4).trim().equals("")) ? "N/A" :
(rs.getString(4).startsWith("3")?
rs.getString(4).substring(1):rs.getString(4)))+
                                 ",null,"+
                                 comp+
                                 ",null,null,null,null,null,null,"+
                                 temp+

",null,null,rs.getString(8),rs.getString(11),rs.getString(10),rs.getString(9
)");

                     dailyResultBean.addRow ( new
HandlerSearchResultBeanRow(null,

rs.getString(1),

(rs.getString(3) == null || rs.getString(3).trim().equals("")) ? "N/A" :
(rs.getString(3).startsWith("3")?
rs.getString(3).substring(1):rs.getString(3)),

(rs.getString(4) == null || rs.getString(4).trim().equals("")) ? "N/A" :
(rs.getString(4).startsWith("3")?
rs.getString(4).substring(1):rs.getString(4)),

null,comp,
                                                                     null,
null, null,null,
                                                                     null,
null,
                                                                     temp,

null,rs.getString(2),null,null,null,rs.getString(8),rs.getString(11),rs.getS
tring(10),rs.getString(9)));
                 }
             dailyResultBean.sortRow1();
             request.setAttribute("dsrb",dailyResultBean);
             for (int iRow = 0; iRow < dailyResultBean.getRowSize() ; ++iRow)
{
			     com.nqb.ps.otcstats.HandlerSearchResultBeanRow row =
dailyResultBean.getRow(iRow);
			     CAT.debug("Retrieved data: "+row.getDate()+"   "+row.getOldSymbol()+
"   "+row.getNewSymbol()+ "   "+row.getCompanyName()+ "
"+row.getSecClass()+"    ");
			 }

             cstmt.close();
             rs.close();
             }
             catch(SQLException e)
             {
                 DB.error("problem closing the cstmt or resultset", e);
                 next = Links.ERROR_PAGE;
             }
             catch(Exception e)
             {
                 CAT.error("general exception occured", e);
                 next = Links.ERROR_PAGE;
             }
         return next;
         }
}




for that I have written the following DailyListingSplitHandlerTest.java
file,




import java.io.*;
import java.sql.*;
import com.informix.jdbc.IfxDriver;

import java.util.*;
import java.lang.*;
import java.text.*;

import javax.servlet.*;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;


//import com.nqb.ps.otcstats.*;
//import com.pinksheets.util.db.*;

import junit.framework.Test;
import junit.framework.TestCase;
import junit.framework.TestSuite;

public class DailyListingSplitHandlerTest  extends TestCase{
     String next;
     RequestObject request;
     ResponseObject response;
     ContextObject context;
     Connection conn;



     public DailyListingSplitHandlerTest(String name) {
         super(name);
     }

     protected void setUp() throws
                 ServletException, IOException {

    com.pinksheets.util.db.DatabaseConnectionPool databaseConnectionPool =
null;
    com.pinksheets.util.db.DatabaseObject dbObj = null;
    RequestObject reqobj = new RequestObject();
    ResponseObject resobj = new ResponseObject();
    ContextObject conobj = new ContextObject();

     try {
			 databaseConnectionPool = new
com.pinksheets.util.db.DatabaseConnectionPool(
"com.informix.jdbc.IfxDriver","url","username","password",5,false );
		 }
		 catch ( Exception e ) {
			 System.out.println( "Error while trying to connect to database. ") ;
		 }
	 try {

     Connection connection =
DriverManager.getConnection("jdbc:informix-sqli://10.53.9.83:1532/pinkstatsd
b:INFORMIXSERVER=pstat1db","informix","eqsdb");

connection.setTransactionIsolation(Connection.TRANSACTION_READ_UNCOMMITTED);
     dbObj = new com.pinksheets.util.db.DatabaseObject(connection);
     }
     catch(SQLException sqle) {
         System.out.println("sql exception" );

     }
     String act = "";
     com.nqb.ps.otcstats.handlers.DailyListingSplitHandler _bean;
     System.out.println("blababaa" + reqobj.getParameter(act));

         _bean = new
com.nqb.ps.otcstats.handlers.DailyListingSplitHandler("Links.DAILY_LISTING_S
PLIT_PAGE",(javax.servlet.http.HttpServletRequest)reqobj,(javax.servlet.http
.HttpServletResponse)resobj,(ServletContext)conobj,dbObj);
         String next = _bean.processRequest();
         System.out.println("next is " + next);

     }

     protected void tearDown() {

     }

		 public void testNumRecords() {
		 int expectedcount = 18;
		 int currentcount = 18;
		 assertEquals(expectedcount,currentcount);
		 }

     public static void main(String[] args) {
         String[] testCaseName =
{DailyListingSplitHandlerTest.class.getName()};
         junit.ui.TestRunner.main(testCaseName);
     }

   }



I have hard coded expected count and currentcount in the testNumRecords to
ensure the top portion is working properly. The RequestObject,ResponseObject
and ContexObject are implemented with dummy values as we can not pass
HttpServletRequest and HttpServletResponse Objects while running the junit.

Its compiling well. It complains during compilation If we do not explictly
cast the RequestObject and ResponseObject with HttpServletRequest and
HttpServletResponse respectively. So I have explicitly casted them.

But I am getting errors at the following line when I run the
DailyListingSplitHandlerTest

_bean = new
com.nqb.ps.otcstats.handlers.DailyListingSplitHandler("Links.DAILY_LISTING_S
PLIT_PAGE",(javax.servlet.http.HttpServletRequest)reqobj,(javax.servlet.http
.HttpServletResponse)resobj,(ServletContext)conobj,dbObj);

The error message is

java.lang.ClassCastException: RequestObject  at
DailyListingSplitHandlerTest.setUp(DailyListingSplitHandlerTest.java:76)


Help..Help..Urgent.

Thanks in advance,
Dinesh

> I have hard coded expected count and currentcount in the testNumRecords to
> ensure the top portion is working properly. The RequestObject,ResponseObject
> and ContexObject are implemented with dummy values as we can not pass
> HttpServletRequest and HttpServletResponse Objects while running the junit.
>
> Its compiling well. It complains during compilation If we do not explictly
> cast the RequestObject and ResponseObject with HttpServletRequest and
> HttpServletResponse respectively. So I have explicitly casted them.

So, RequestObject does not implement HttpServletRequest and ResponseObject does
not implement HttpServletRequest? Otherwise the compiler would not require you
to cast them.

> The error message is
>
> java.lang.ClassCastException: RequestObject at
> DailyListingSplitHandlerTest.setUp(DailyListingSplitHandlerTest.java:76)

The compiler is telling you that RequestObject is of the wrong type. It should
implement the HttpServletRequest, which is what you told the constructor to
expect.

Steve

Thanks.

-----Original Message-----
From: Steve Freeman [mailto:steve@...]
Sent: Saturday, August 04, 2001 12:49 PM
To: junit@yahoogroups.com
Subject: Re: [junit] cast exception during run time


> I have hard coded expected count and currentcount in the testNumRecords to
> ensure the top portion is working properly. The
RequestObject,ResponseObject
> and ContexObject are implemented with dummy values as we can not pass
> HttpServletRequest and HttpServletResponse Objects while running the
junit.
>
> Its compiling well. It complains during compilation If we do not explictly
> cast the RequestObject and ResponseObject with HttpServletRequest and
> HttpServletResponse respectively. So I have explicitly casted them.

So, RequestObject does not implement HttpServletRequest and ResponseObject
does not implement HttpServletRequest? Otherwise the compiler would not
require you to cast them.

> The error message is
>
> java.lang.ClassCastException: RequestObject at
> DailyListingSplitHandlerTest.setUp(DailyListingSplitHandlerTest.java:76)

The compiler is telling you that RequestObject is of the wrong type. It
should implement the HttpServletRequest, which is what you told the
constructor to expect.

Steve



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/

One of the distinctions I have often found useful is whether a failure
is a test precondition or postcondition failure. This is especially
true where there is a deep tree of dependencies in the testcases (which is
often the case). A single bug can cause hundreds of failures; Only one
failure is probably significant. We had an in-house test harness at some
point that had assertions which would return different result codes on
failure. One of them was INCOMPLETE. A test would be INCOMPLETE if
something failed in setting up the test indicating a problem with a
dependency which is not the direct purpose of the test. Semi-contrived
example:

void testConnectLogger()
{
	 precondition(d_logger.isOpen());
	 precondition(d_logger.queue().isEmpty());

	 d_service.connectLogger(d_logger);

	 postcondition(d_service.getLogger() == d_logger);
	 postcondition(d_logger.queue().size() == 1);
} // testConnectLogger()

If the preconditions fail, it means that the test couldn't run, not that
it "fails" per se. Precondition failure were enough to fail an entire
run, but they were tallied separately. If you see:

RUN: 45
FAILED: 1
INCOMPLETE: 33

[Test testSomeDependencyOrOther FAILED]

...

It's very obvious what the culprit is. Exceptions in setUp()
methods should also cause tests in that unit to be INCOMPLETE.
Another useful thing is to be able to write code like:

void testSpecialCall()
{
	 if (!HAVE_SPECIAL_LIB) cancel();

	 postcondition(specialCall() == 5);
} // testSpecialCall()

Certain tests may be inappropriate in certain environs. You don't want
these tests to pass, since that's misleading. You certainly don't want
them to fail though, because determining whether or not a test run was
successful overall becomes error-prone. It's nice to have a count of the
tests that ended up being inappropriate for a particular setup.

On Fri, 3 Aug 2001, David Avraamides wrote:

> > Agreed; however, I find it nice to go on the
> > assumption that a failure means
> > my code is broken and an error means my test is
> > broken. I wonder if not many
> > people find this useful or if I'm overstating how
> > useful it can be.
>
> In the past I tried to make this same distinction, but
> I found in practice that it was often arbitrary.
> Often, I'll change code that invalidates existing test
> cases so they start throwing assertions. The code
> isn't broken, the problem is that the test cases are
> out of sync with the code since the assumptions have
> changed. To me, it doesn't really matter what's broken
> (testing code or tested code) or how I'm notified of
> the problem (assertion or error). The point is that I
> need to investigate the problem and fix it.
>
> For me, the path of least resistance is the most
> effective: make my test cases simple to write and
> simple to understand. Thus, I prefer letting JUnit
> handle uncaught exceptions as errors since this:
>
>   public void testFoo() throws Exception {
>     code;
>   }
>
> is simpler than:
>
>   public void testFoo() {
>     try {
>       code;
>     catch (ErrorException e) {
>       fail(...);
>     }
>   }
>
> Both versions say the same thing to me: I expect
> "code" to work, and if it doesn't something is wrong.
> I just find the latter case less clear.
>
> My two cents...
>
>
>
> __________________________________________________
> Do You Yahoo!?
> Make international calls for as low as $.04/minute with Yahoo! Messenger
> http://phonecard.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/
>
>
>

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

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

We are developing a J2EE-based web application, and we've been
getting better and better at our testing.  Recently we reached
a pain threshold that's causing us to make a compromise trade
off.  Perhaps you folks can offer some suggestions.

The developers write unit test for all layers of the system,
from the web pages to the smallest methods.  For most tests,
we use JUnit and for the web tests we use HTTPUnit.

The highest level of the web tests check for the page flow
(link navigation) and for page contents.  These tests, written
with HTTPUnit, are getting painful.  There is often a lot of
set up needed (e.g., putting objects in the right state) to
get to the point where the test can execute, as well as a lot
of code to log in and navigate to the page where the test can
run.  In some cases, the effort to write these tests is a
significant percentage of the overall task efforts.

Recently, developers have stopped writing these web tests,
resorting to running the tests manually by hand.  Their
reasoning is that the cost of writing the web tests is not
justified by their benefits.  Others point out the issues
with manual tests (inconsistent tests, the extra time to run
them repeatedly, lack of documentation, etc.), and assert
that the tests are worth the admittedly high costs.  We're
having trouble reaching consensus.

A related issue is that our QA folks have not been able to
provide a suite of automated acceptance tests, which we
presume should also test page navigation and contents as page
of the user functionality tests.  They use a "big" testing
tool (Seque), and we're not sure if we could use their tests
in a day-to-day development environment, if they existed.

So, in your opinion, should the developers be writing the web
page navigation and contents tests?  IMHO, we should because
this stuff can break, unless we can get QA to write them as
part of the acceptance tests and we can share the tool to run
them in the development environment.

If so, should the tests be automated?  IMHO, they should for
all the same reasons we automate any tests.

Now, what about the cost?  Are there ways to reduce the costs
of writing these type of tests?  Are there other tools we
could be using?  At XPU, Lisa Crispin recommended WebART as
a tool at this level.  I also heard discussion of patterns
such as Object Mother for creating objects in a particular
state for testing.  Comments here?

Thanks much in advance for any suggestions.

-Paul Hodgetts

In my opinion, developers should not write the web page navigation
and contents tests.  This is not unit testing.  This is functional
testing that should be done by the QA team.  Although I admit the
line between unit and functional testing is sometimes blurry.

An effective approach would be to use a design pattern called Front
Controller:  "Centralize view management (navigation, templating,
security, etc.) for a Web application in a single object that handles
incoming client requests ."

(http://java.sun.com/j2ee/blueprints/design_patterns/front_controller/index.html\
).

With Front Controller you can gut all of your business logic out of
your servlets and JSPs.  Your business logic would be contained in
separate classes which can be unit tested.

Mike

--- Paul Hodgetts <prh@...> wrote:
> We are developing a J2EE-based web application, and we've been
> getting better and better at our testing.  Recently we reached
> a pain threshold that's causing us to make a compromise trade
> off.  Perhaps you folks can offer some suggestions.
>
> The developers write unit test for all layers of the system,
> from the web pages to the smallest methods.  For most tests,
> we use JUnit and for the web tests we use HTTPUnit.
>
> The highest level of the web tests check for the page flow
> (link navigation) and for page contents.  These tests, written
> with HTTPUnit, are getting painful.  There is often a lot of
> set up needed (e.g., putting objects in the right state) to
> get to the point where the test can execute, as well as a lot
> of code to log in and navigate to the page where the test can
> run.  In some cases, the effort to write these tests is a
> significant percentage of the overall task efforts.
>
> Recently, developers have stopped writing these web tests,
> resorting to running the tests manually by hand.  Their
> reasoning is that the cost of writing the web tests is not
> justified by their benefits.  Others point out the issues
> with manual tests (inconsistent tests, the extra time to run
> them repeatedly, lack of documentation, etc.), and assert
> that the tests are worth the admittedly high costs.  We're
> having trouble reaching consensus.
>
> A related issue is that our QA folks have not been able to
> provide a suite of automated acceptance tests, which we
> presume should also test page navigation and contents as page
> of the user functionality tests.  They use a "big" testing
> tool (Seque), and we're not sure if we could use their tests
> in a day-to-day development environment, if they existed.
>
> So, in your opinion, should the developers be writing the web
> page navigation and contents tests?  IMHO, we should because
> this stuff can break, unless we can get QA to write them as
> part of the acceptance tests and we can share the tool to run
> them in the development environment.
>
> If so, should the tests be automated?  IMHO, they should for
> all the same reasons we automate any tests.
>
> Now, what about the cost?  Are there ways to reduce the costs
> of writing these type of tests?  Are there other tools we
> could be using?  At XPU, Lisa Crispin recommended WebART as
> a tool at this level.  I also heard discussion of patterns
> such as Object Mother for creating objects in a particular
> state for testing.  Comments here?
>
> Thanks much in advance for any suggestions.
>
> -Paul Hodgetts
>
>


__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

Mike Duffy wrote:

  > In my opinion, developers should not write the web page navigation
  > and contents tests.  This is not unit testing.  This is functional
  > testing that should be done by the QA team.  Although I admit the
  > line between unit and functional testing is sometimes blurry.

Yes, it is a blurry line.  IMHO, the QA team should write tests
that prove the functionality is available to the user.  Since the
user accesses the application via the web pages, this would imply
that they would need to write tests that simulate the user's use
of the web pages.  But I'm not sure that these functional tests
would always test the implementation of the web pages, which is
where the developers may need to supplement them with tests that
understand the underlying implementation and poke at it.

The main reason we would have the developers write these tests
is because QA does not yet have the capabilities to write and
perform these tests, which we can solve by increasing their
capabilities.  For now we have to cover this somehow.

In addition to QA not being able to perform these tests,
there's also an issue with trying to catch these errors as
early in the release cycle as possible.  The developers really
should be regularly running all the web tests.  If the tests
are too time consuming to run as part of the pre-check in
suite, maybe we just run them a few times a day as part of a
background build verify process.  If these errors make it to
a QA build, it takes more effort to fix them and then build
and deploy new releases than it does to catch them sooner.  We
can work on making the release to QA easier and more a part of
the daily process, rather than a discrete step.

How does your process work in these areas?

  > An effective approach would be to use a design pattern called Front
  > Controller:  "Centralize view management (navigation, templating,
  > security, etc.) for a Web application in a single object that handles
  > incoming client requests ."
  >
  >
(http://java.sun.com/j2ee/blueprints/design_patterns/front_controller/index.
html\).
  >
  >
  > With Front Controller you can gut all of your business logic out of
  > your servlets and JSPs.  Your business logic would be contained in
  > separate classes which can be unit tested.

Yes, we use this pattern, along with other J2EE presentation
patterns.  Even with Front Controllers, and View Helpers, and
other things that drive code off of the pages, there is still
a layer, however thin, that rests on the surface area of the
application.  IMHO, we still need to verify that this layer
contains the correct contents and links, and perhaps even has
them displayed at the correct position in the correct font,
color, etc.  Also, the underlying controllers and helpers
have a degree of dependency on things like the HTTP request
and session, so it's not always simple to test them in
isolation from the web context.  How do you deal with these
issues?

Thanks for your comments,
-Paul Hodgetts