I like your approach, and we've done something not very similar. In our
enviornment we purposely removed our 'outside' tests ( httpunit functional
tests ) from our code that implements the application. They are in fact
in different projects altogether and the httpunit tests do not depend on
any code from the system itself. This way we can fully test the system
from the 'outside'. It does have the drawback that you've solved using
static accessors though. I think it is nice to have the
action/formhandling code and the template be in sync.
In our testing I found that we've used httpunit for two things: test drive
the app from the users perspective and verify the html is generating
correctly. From a programmer/developer perspective, it would be nice to
have a way to render a template for testing to verify it is correct. It
may not have to function, but test that there are no velocity/rendering
issues.
The driving of the application could/may then be slightly under the UI,
say maybe just accessing the model or something.
Another drawback to how we've used httpunit is that the interface is
tightly coupled to the tests now. Changing around the layout of the page,
even if it didn't change functionality much, has a nasty ripple
effect. We are now trying to reduce this coupling when possible.
On Fri, 20 Dec 2002, Sam Joseph wrote:
> Hi All,
>
> So anyway, I had this idea.
>
> Recently I am doing a lot of work with html templates (using the
> Velocity Templating language).
>
> Anyway, the thing is that I have lots of lots of web management screens
> of one sort or another. Each screen is backed by a template, and some
> associated code. I have a ControllerServlet passing off requests to
> particular templates and processing the associated code.
>
> I do some of this in Turbine (which handles a lot of things
> automatically), and some of it not. Either way the paradigm is the same.
>
> Recently I have acquired two habits that I believe are helping me
> produce working, effective management screens.
>
> 1. I define all HTML form variables in the code associated with the template
> 2. I use HttpUnit to check that the forms work properly
>
> These two things are related. The function of the first is so that when
> I am checking a parameter from a submitted form, I know that I am
> checking for precisely the parameter specified in the form, e.g.
>
> **Template segment**
>
> <form name="$EDIT_FORM" action="$FORM_ACTION" method="POST">
> <input type="hidden" name="$ACTION" value="$ACTION_TYPE">
>
> **Template generation Code segment**
>
> public class AddBookmarkCommand
> {
>
> public static final String ACTION = "action";
> public static final String EDIT_FORM = "edit_form";
> public static final String FORM_ACTION = "/neurogrid/servlet/forum";
> public static final String ACTION_TYPE = "add_bookmark";
>
> public void generateTemplate(VelocityContext p_context)
> {
> p_context.put("ACTION",ACTION);
> p_context.put("EDIT_FORM",EDIT_FORM);
> p_context.put("FORM_ACTION",FORM_ACTION);
> p_context.put("ACTION_TYPE",ACTION_TYPE);
>
> **Form handling code segment**
>
> public class AddBookmarkCommand
> {
>
> String x_action = request.getParameter(ACTION);
> if(x_action.equals(ACTION_TYPE))
> {
> // do some stuff
>
> Anyway, I'm not sure how clear the above example is, and it probably
> helps if you know Velocity, but the point is that when I am checking for
> attribute/value pairs coming in from html form submissions I know the
> form has been supplied with precisely those values.
>
> The HttpUnit code goes something like this:
>
> WebResponse x_jdoc = o_wc.getCurrentPage();
> WebForm x_form = x_jdoc.getFormWithName(AddBookmarkCommand.EDIT_FORM);
>
> So perhaps you can see the relation. I am also able to access the static
> final HTML form attributes in the test code to ensure that there is no
> confusion. Everything that is going to interact with these
> attribute/value pairs is refering to precisely the same things.
>
> So one thing I am interested in is getting some feedback on the above
> approach.
>
> The other thing is that I am thinking about taking all this a step
> further. It would seem possible to write some code that would take an
> html template and automatically generate java code that would serve as
> the form handling code as well as the testing code. So you write your
> template, and then press a button, and hey presto you have a form
> handling class that will specify all the necessary final static
> variables, and testing code that will check if they are present when you
> view the template.
>
> There is a system that sort of does this called Canoo WebTest which I
> have been looking at, where you can specify test cases in the form of
> XML. However I don't see anyway to link the attribute/value pairs
> throughout, in the way I describe above.
>
> Alot of my work involves writing and testing web management screens and
> it would be great to be able to streamline the process.
>
> However maybe I am overlooking some serious flaws in my appoach? Any
> comments?
>
> CHEERS> SAM
>
>
>
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
--
=====================================================================
Jeffrey D. Brekke [EMAIL PROTECTED]
Wisconsin, USA [EMAIL PROTECTED]
[EMAIL PROTECTED]
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
