You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by James Turner <tu...@blackbear.com> on 2003/02/05 06:52:21 UTC

Need help deciphering screw-case for PR 15799

I've taken a look at the code for 15799, but I'm still not exactly sure
what problem was being reported.  I don't feel comfortable applying a
patch for a problem that isn't properly documented.  Anyone got a clue?

James Turner
Owner & Manager, Black Bear Software, LLC
turner@blackbear.com

Author: 
    MySQL & JSP Web Applications: 
        Data Driven Programming Using Tomcat and MySQL
    ISBN 0672323095; Sams, 2002

Co-Author: 
    Struts Kick Start
    ISBN 0672324725; Sams, 2002

Forthcoming:
    JavaServer Faces Kick Start 
    Sams, Fall 2003



---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org


Re: Need help deciphering screw-case for PR 15799

Posted by Martin Cooper <ma...@apache.org>.
I looked at this one too, and came out with similar feelings. I think this
needs the eyes of our resident Keyboard Monkey, if he's around.

Calling all Keyboard Monkeys... We need your help...

--
Martin Cooper


On Wed, 5 Feb 2003, James Turner wrote:

> I've taken a look at the code for 15799, but I'm still not exactly sure
> what problem was being reported.  I don't feel comfortable applying a
> patch for a problem that isn't properly documented.  Anyone got a clue?
>
> James Turner
> Owner & Manager, Black Bear Software, LLC
> turner@blackbear.com
>
> Author:
>     MySQL & JSP Web Applications:
>         Data Driven Programming Using Tomcat and MySQL
>     ISBN 0672323095; Sams, 2002
>
> Co-Author:
>     Struts Kick Start
>     ISBN 0672324725; Sams, 2002
>
> Forthcoming:
>     JavaServer Faces Kick Start
>     Sams, Fall 2003
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org


Re: Need help deciphering screw-case for PR 15799

Posted by "David M. Karr" <dm...@earthlink.net>.
>>>>> "James" == James Turner <tu...@blackbear.com> writes:

    James> I've taken a look at the code for 15799, but I'm still not exactly sure
    James> what problem was being reported.  I don't feel comfortable applying a
    James> patch for a problem that isn't properly documented.  Anyone got a clue?

If the reporter doesn't reply to the request for more information, I would
leave it alone for now.

-- 
===================================================================
David M. Karr          ; Java/J2EE/XML/Unix/C++
dmkarr@earthlink.net   ; SCJP; SCWCD




---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org


Unit Test Was Re: Need help deciphering screw-case for PR 15799

Posted by Vic Cekvenich <vc...@basebeans.com>.
James Turner wrote:
> 
> 
> I have major problems (both for Struts and with my client's projects)
> about regression testing, specifically with JSP.  This is really causing
> problems for us in Struts, because many of the things that are coming up
> are taglib-related and nearly impossible to accurately unit-test.
> 
> I'd love to see a good solution proposed for this, I've tried Cactus and
> it's a good half-way step, but still doesn't really test the code on the
> JSP page.

SNIP

I find most errors are data model changes, etc, that show up as JSP.

A dirty solution I have used successfully :
- be religious about testing! a bean that does not work (unit test) 
outside of Struts, will not start working inside of Struts/JSP. A bean 
must multi row, master/Detail (via nesting), crud, via a DAO helper, etc.
  A beans "contract" is the JSP fields.

- I create an abstract String TestIt() method in "baseFormBean". It 
extends validatorformbean. (I avoid Dynabeans because I can't test it, 
hence it is risky. Also somtimes I do use bean Model 1 style or 
JavaScript, or Soap, or c:tag, or display tag, etc. So I just like plain 
bean.)
- People write retrieve, update, insert, getters methods in concreate 
beans, they must; it won't compile -it's abstract.
- I have a servlet that does new of every bean, and does testIt.
- I check the log, and see any fatal or error's, the regresion failed! 
log info just shows the data before and after Crud. Multi row CRUD as 
well (another topic, but "my" formbeans implement collection in base, 
and nesting them makes it Master/Detail. Of course, you can have 2 sets 
of beans and copy)
-The formBean must match the JSP needs, that that is what you unit test, 
the "contract" of the JSP; I program to requirments. A client can make 
up any HTML they want, I rename file to JSP; that is my contract! Now I 
write the unit test (testIt) and go back to write a DAO instance to help 
me get the data (clients don't care about how I get the data or where it 
is, neither does my bean)

Also: When clients ask me for tech support on JSP, I say, show me the 
output of the testIt log "file" for that formBean. Bingo!

To place a tested bean in Struts is trivial!
To run testIt() servelt, that tests all the beans, is trivial. You can 
even have the servelt fire at 5PM every day (via web.xml)
Source is in basicPortal, should you want the quick/dirty.

I do not think the testing tool is important, once you grasp that unit 
testing speeds development.
Hard time I have is managers saying, we are on a short deadline, we do 
not have time to test..... of course, the shorter the deadline, the more 
testing you need. Which is what a consultant does, shows them how to 
shave time.

I do not know how to test a JSP, nor do I have major erros there. Mostly 
JavaScript errors... yuck!

.V



---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org


RE: Need help deciphering screw-case for PR 15799

Posted by "Craig R. McClanahan" <cr...@apache.org>.

On Wed, 5 Feb 2003, James Turner wrote:

> Date: Wed, 5 Feb 2003 01:48:24 -0500
> From: James Turner <tu...@blackbear.com>
> Reply-To: Struts Developers List <st...@jakarta.apache.org>
> To: 'Struts Developers List' <st...@jakarta.apache.org>
> Subject: RE: Need help deciphering screw-case for PR 15799
>
> > The other thing we all need to get better about is committing
> > test cases to the (currently pretty woeful) unit tests in
> > Struts, so that we can protect ourselves against regressions
> > later.  But I'm willing to forgo that for now, as long as we
> > (as a group) make it a high priority post-1.1 goal.
>
>
> I have major problems (both for Struts and with my client's projects)
> about regression testing, specifically with JSP.  This is really causing
> problems for us in Struts, because many of the things that are coming up
> are taglib-related and nearly impossible to accurately unit-test.
>
> I'd love to see a good solution proposed for this, I've tried Cactus and
> it's a good half-way step, but still doesn't really test the code on the
> JSP page.
>

Ted seems to like strutstestcase more than he likes me now (to quote him,
"strutstestcase is my new best friend" :-)

More seriously, I would be *delighted* if Struts > 1.1 included built-in
mechanisms for unit testing the application components required by the
framework, complete with example unit tests for all of the included
example apps.  Creating a cool framework is getting to be a "been there,
done that" for us.  Creating a cool framework that includes direct support
for unit testing application components built on top of the framework
would be much better than cool.

> James Turner
> Owner & Manager, Black Bear Software, LLC
> turner@blackbear.com
>

Craig


> Author:
>     MySQL & JSP Web Applications:
>         Data Driven Programming Using Tomcat and MySQL
>     ISBN 0672323095; Sams, 2002
>
> Co-Author:
>     Struts Kick Start
>     ISBN 0672324725; Sams, 2002
>
> Forthcoming:
>     JavaServer Faces Kick Start
>     Sams, Fall 2003
>
>
> > -----Original Message-----
> > From: Craig R. McClanahan [mailto:craigmcc@apache.org]
> > Sent: Wednesday, February 05, 2003 1:40 AM
> > To: Struts Developers List
> > Subject: Re: Need help deciphering screw-case for PR 15799
> >
> >
> >
> >
> > On Wed, 5 Feb 2003, James Turner wrote:
> >
> > > Date: Wed, 5 Feb 2003 00:52:21 -0500
> > > From: James Turner <tu...@blackbear.com>
> > > Reply-To: Struts Developers List <st...@jakarta.apache.org>
> > > To: struts-dev@jakarta.apache.org
> > > Subject: Need help deciphering screw-case for PR 15799
> > >
> > > I've taken a look at the code for 15799, but I'm still not exactly
> > > sure what problem was being reported.  I don't feel comfortable
> > > applying a patch for a problem that isn't properly
> > documented.  Anyone
> > > got a clue?
> > >
> >
> > Asking the initial bug reporter for a failure case (even if
> > it takes a direct email) is always good -- and it's
> > absolutely the right thing to do. If you can't prove that the
> > current code doesn't fail, you can't prove that any new code
> > succeeds.  Don't feel bad about closing it with WORKSFORME if
> > you can't reproduce it or acquire a test case.
> >
> > The other thing we all need to get better about is committing
> > test cases to the (currently pretty woeful) unit tests in
> > Struts, so that we can protect ourselves against regressions
> > later.  But I'm willing to forgo that for now, as long as we
> > (as a group) make it a high priority post-1.1 goal.
> >
> > Craig
> >
> > > James Turner
> > > Owner & Manager, Black Bear Software, LLC turner@blackbear.com
> > >
> > > Author:
> > >     MySQL & JSP Web Applications:
> > >         Data Driven Programming Using Tomcat and MySQL
> > >     ISBN 0672323095; Sams, 2002
> > >
> > > Co-Author:
> > >     Struts Kick Start
> > >     ISBN 0672324725; Sams, 2002
> > >
> > > Forthcoming:
> > >     JavaServer Faces Kick Start
> > >     Sams, Fall 2003
> > >
> > >
> > >
> > >
> > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: struts-dev-help@jakarta.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: struts-dev-help@jakarta.apache.org
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org


Re: Need help deciphering screw-case for PR 15799

Posted by Ted Husted <hu...@apache.org>.
I'm working on JUnit book with Vincent Massol that includes a chapter 
about UnitTesting JSPs with Cactus and/or Mock Objects. This chapter's 
still in the first draft stage, but I'll let everyone know when its 
ready for public review. Should be coming up soon.

We cover two types of tests for JSPs,

* Isolate the JSP from the back end by mocking the input JavaBeans it 
uses, and then verifying that the returned page contains the expected data.

* Direct tests on JSP custom tags used in the JSP with either Cactus or 
Mock Objects.

All my new development is test-first now. The idea being, if your going 
to write the test anyway, you might as well write the test first and get 
the most use out of it. Typically, I have a core Unit Test for the back 
end code and then Struts TestCases for the Actions.

It's getting so that I have to remind myself to click through the 
application now and again, just to be absolutely sure its passing the 
"acceptance tests".

-Ted.

And, Craig, Deryl's Struts TestCase may be way-cool and fashionable, but 
you're still like a brother to me =:0)

James Turner wrote:
>>The other thing we all need to get better about is committing 
>>test cases to the (currently pretty woeful) unit tests in 
>>Struts, so that we can protect ourselves against regressions 
>>later.  But I'm willing to forgo that for now, as long as we 
>>(as a group) make it a high priority post-1.1 goal.
> 
> 
> 
> I have major problems (both for Struts and with my client's projects)
> about regression testing, specifically with JSP.  This is really causing
> problems for us in Struts, because many of the things that are coming up
> are taglib-related and nearly impossible to accurately unit-test.
> 
> I'd love to see a good solution proposed for this, I've tried Cactus and
> it's a good half-way step, but still doesn't really test the code on the
> JSP page.



-- 
Ted Husted,
Struts in Action <http://husted.com/struts/book.html>


---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org


RE: Need help deciphering screw-case for PR 15799

Posted by James Turner <tu...@blackbear.com>.
> The other thing we all need to get better about is committing 
> test cases to the (currently pretty woeful) unit tests in 
> Struts, so that we can protect ourselves against regressions 
> later.  But I'm willing to forgo that for now, as long as we 
> (as a group) make it a high priority post-1.1 goal.


I have major problems (both for Struts and with my client's projects)
about regression testing, specifically with JSP.  This is really causing
problems for us in Struts, because many of the things that are coming up
are taglib-related and nearly impossible to accurately unit-test.

I'd love to see a good solution proposed for this, I've tried Cactus and
it's a good half-way step, but still doesn't really test the code on the
JSP page.

James Turner
Owner & Manager, Black Bear Software, LLC
turner@blackbear.com

Author: 
    MySQL & JSP Web Applications: 
        Data Driven Programming Using Tomcat and MySQL
    ISBN 0672323095; Sams, 2002

Co-Author: 
    Struts Kick Start
    ISBN 0672324725; Sams, 2002

Forthcoming:
    JavaServer Faces Kick Start 
    Sams, Fall 2003


> -----Original Message-----
> From: Craig R. McClanahan [mailto:craigmcc@apache.org] 
> Sent: Wednesday, February 05, 2003 1:40 AM
> To: Struts Developers List
> Subject: Re: Need help deciphering screw-case for PR 15799 
> 
> 
> 
> 
> On Wed, 5 Feb 2003, James Turner wrote:
> 
> > Date: Wed, 5 Feb 2003 00:52:21 -0500
> > From: James Turner <tu...@blackbear.com>
> > Reply-To: Struts Developers List <st...@jakarta.apache.org>
> > To: struts-dev@jakarta.apache.org
> > Subject: Need help deciphering screw-case for PR 15799
> >
> > I've taken a look at the code for 15799, but I'm still not exactly 
> > sure what problem was being reported.  I don't feel comfortable 
> > applying a patch for a problem that isn't properly 
> documented.  Anyone 
> > got a clue?
> >
> 
> Asking the initial bug reporter for a failure case (even if 
> it takes a direct email) is always good -- and it's 
> absolutely the right thing to do. If you can't prove that the 
> current code doesn't fail, you can't prove that any new code 
> succeeds.  Don't feel bad about closing it with WORKSFORME if 
> you can't reproduce it or acquire a test case.
> 
> The other thing we all need to get better about is committing 
> test cases to the (currently pretty woeful) unit tests in 
> Struts, so that we can protect ourselves against regressions 
> later.  But I'm willing to forgo that for now, as long as we 
> (as a group) make it a high priority post-1.1 goal.
> 
> Craig
> 
> > James Turner
> > Owner & Manager, Black Bear Software, LLC turner@blackbear.com
> >
> > Author:
> >     MySQL & JSP Web Applications:
> >         Data Driven Programming Using Tomcat and MySQL
> >     ISBN 0672323095; Sams, 2002
> >
> > Co-Author:
> >     Struts Kick Start
> >     ISBN 0672324725; Sams, 2002
> >
> > Forthcoming:
> >     JavaServer Faces Kick Start
> >     Sams, Fall 2003
> >
> >
> >
> > 
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: struts-dev-help@jakarta.apache.org
> >
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org


Re: Need help deciphering screw-case for PR 15799

Posted by "Craig R. McClanahan" <cr...@apache.org>.

On Wed, 5 Feb 2003, James Turner wrote:

> Date: Wed, 5 Feb 2003 00:52:21 -0500
> From: James Turner <tu...@blackbear.com>
> Reply-To: Struts Developers List <st...@jakarta.apache.org>
> To: struts-dev@jakarta.apache.org
> Subject: Need help deciphering screw-case for PR 15799
>
> I've taken a look at the code for 15799, but I'm still not exactly sure
> what problem was being reported.  I don't feel comfortable applying a
> patch for a problem that isn't properly documented.  Anyone got a clue?
>

Asking the initial bug reporter for a failure case (even if it takes a
direct email) is always good -- and it's absolutely the right thing to do.
If you can't prove that the current code doesn't fail, you can't prove
that any new code succeeds.  Don't feel bad about closing it with
WORKSFORME if you can't reproduce it or acquire a test case.

The other thing we all need to get better about is committing test cases
to the (currently pretty woeful) unit tests in Struts, so that we can
protect ourselves against regressions later.  But I'm willing to forgo
that for now, as long as we (as a group) make it a high priority post-1.1
goal.

Craig

> James Turner
> Owner & Manager, Black Bear Software, LLC
> turner@blackbear.com
>
> Author:
>     MySQL & JSP Web Applications:
>         Data Driven Programming Using Tomcat and MySQL
>     ISBN 0672323095; Sams, 2002
>
> Co-Author:
>     Struts Kick Start
>     ISBN 0672324725; Sams, 2002
>
> Forthcoming:
>     JavaServer Faces Kick Start
>     Sams, Fall 2003
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org