> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, December 14, 2004 3:15 PM
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Tips on testing pages with multiple potential paths?
> Importance: High
> 
> 
> We have an application where each page has about 8 different 
> paths depending upon the DTO in session, and the values 
> passed in the request.
> I have only started on the 1st page right now, and feel 
> overwhelmed with the limitless possibilities I have to test for.
> I am hoping someone can give me some tips to be able make my 
> test writing easier, and potentially re-usable.
> The generic examples just don't address trying to do complex 
> multi-path scenarios.
> 
> I am using CactusStrutsTestCase currently.

This is one of the reasons why I stopped using Cactus a long time ago.  I found 
it easier to test the individual action 
(http://strutstestcase.sourceforge.net/) then I did the page, conceptually for 
me at least.
However, I think what you posted earlier was a great start.   You're right 
though, it is a daunting task to build a robust test suite.  If you're thinking 
I'll have as many lines of code in your test suite as your project, you're 
probably right there too.  It's not easy.
The best piece of advice I've ever heard is to write your test software with 
the same attitude you write your main code.  If a test case, or the entire 
suite needs to be refactored, do it.  I've also noticed that with rare 
exception each project tends to end up with it's own unique patterns to a large 
degree.  
Test one thing at a time.  If you're testing the Presentation layer, leave the 
business objects and dao objects out of the picture.  If you can't do that 
easily, it's probably time to re-factor your architecture so you can test it 
easier.
Read every thing you can on Mock Objects... they are great things if you know 
how to use them.


> 
> --------------------
> Mick Knutson
> Wells Fargo Business Direct Information Systems
> (415) 222-1020
> 
> "This message may contain confidential and/or privileged 
> information. If you are not the addressee or authorized to 
> receive this for the addressee, you must not use, copy, 
> disclose, or take any action based on this message or any 
> information herein. If you have received this message in 
> error, please advise the sender immediately by reply e-mail 
> and delete this message. Thank you for your cooperation."
> --------------------
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 

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

Reply via email to