The problem with writing against a Use Case is that your test becomes large
and brittle.  Unit testing only works well when you test a very small chunk
of code, therefore you write more against methods.

For testing a use case, well then for webapps I would write a script using
something like Webtest or jwebtest (sp?) to simulate a user performing a use
case.

I would love to see those tests, one of the things Turbine needs are tests
against all the code pulled out into commons so that as they change, Turbine
can be tested against them (although Gump helps here as well).

Eric

-----Original Message-----
From: Peter Courcoux [mailto:[EMAIL PROTECTED]
Sent: Saturday, June 14, 2003 10:43 AM
To: Turbine Developers List
Subject: RE: [PATCH] UIManager


Eric,

Thanks,

Is there a general principal, as to the granularity of tests, should
they be written against methods or 'use cases'?

I guess if they are written against public methods then you cover the
the use cases as well and its easier to deal with when a test fails.
Does this make sense?

This week I've got the file upload progress stuff in use in production
with turbine 2.3. I want to write some tests to submit for both
commons-fileupload and turbine. 

Regards,

Peter

On Sat, 2003-06-14 at 01:29, [EMAIL PROTECTED] wrote:
> Urgh..  YOu asked the difficult question!  Cactus, Junit, or HttpUnit....
> 
> Following the KISS principle, if you can write your test using JUnit, that
> is best, because it involves the fewest moving parts.  HttpUnit, because
> Maven doesn't provide an integrated plugin requires the most.  And Cactus,
> well, I find it very heavy for testing...  Take a look at the src/test
tree
> of code, there is code testing templates.  I feel somewhat like code
testing
> finding templates/screens/actions is showhow similar...
> 
> If this doesn't help, let me know and I'll try and make a more concrete
> suggestions!
> 
> Long live test driven development!
> 
> Eric
> 
> -----Original Message-----
> From: Peter Courcoux [mailto:[EMAIL PROTECTED]
> Sent: Friday, June 13, 2003 6:42 PM
> To: Turbine Developers List
> Subject: RE: [PATCH] UIManager
> 
> 
> Eric,
> 
> In the dim and distant past I did look at an XP site and vow to write
> tests  -  I think I even recall writing one ... you can guess what
> happened. 
> 
> Good motivation though. Keep it up. 
> 
> The issue is the corruption of the Properties object, which is supposed
> to be session scoped, by concurrent users. 
> 
> Could you make the learning curve a bit more shallow for me and point me
> in the right direction, may be even a test that I could adapt. Should I
> be looking at JUnit, HttpUnit or Cactus for this type of thing.  
> 
> Regards,
> 
> Peter 
> 
> 
> 
> On Fri, 2003-06-13 at 22:45, [EMAIL PROTECTED] wrote:
> > Do you by chance have a testcase that demonstrates this?  If you could
add
> > one, I;ll go ahead and commit your change..   
> > 
> > On my quest to get more testcases!
> > 
> > Eric
> > 
> > -----Original Message-----
> > From: Peter Courcoux [mailto:[EMAIL PROTECTED]
> > Sent: Friday, June 13, 2003 5:43 PM
> > To: Turbine Developers List
> > Subject: [PATCH] UIManager
> > 
> > 
> > Hi,
> > 
> > I attach a patch for your consideration.
> > 
> > Skins for the UIManager were being corrupted by other users skins, when
> > the UIManager is being used as a session scoped tool. Turns out that the
> > Skin Properties are held in a static property of the class!
> > 
> > The patch simply removes the 'static' keyword.
> > 
> > Regards,
> > 
> > Peter
> > 
> > Index: UIManager.java
> > ===================================================================
> > RCS file:
> >
>
/home/cvspublic/jakarta-turbine-2/src/java/org/apache/turbine/services/pull/
> > util/UIManager.java,v
> > retrieving revision 1.9
> > diff -u -r1.9 UIManager.java
> > --- UIManager.java  3 Jun 2003 13:41:27 -0000       1.9
> > +++ UIManager.java  13 Jun 2003 21:32:48 -0000
> > @@ -182,7 +182,7 @@
> >       * Properties to hold the name/value pairs
> >       * for the skin.
> >       */
> > -    private static Properties skinProperties;
> > +    private Properties skinProperties;
> >  
> >      /**
> >       * Initialize the UIManager object.
> > 
-- 
Peter Courcoux <[EMAIL PROTECTED]>

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to