You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@turbine.apache.org by Sam Joseph <ga...@yha.att.ne.jp> on 2002/12/20 06:04:45 UTC
An idea about HTML templates and Testing
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: An idea about HTML templates and Testing
Posted by Sam Joseph <ga...@yha.att.ne.jp>.
Hi Jeffrey,
Jeffrey D. Brekke wrote:
>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.
>
My test code is in a separate project too. I just include classpath
access to the jar file of the main code in order to access the static
items. I guess one could work on making the access completely
restricted to this ....
However there are interesting issues. For example, say you have a web
screen that allows the user to specify a url. The url is then parsed
and some statisics from that page are displayed. How does the httpUnit
test check that these statistics regarding the url are correct? Clearly
httpUnit tst needs to access the same statistical methods that are in
use my the implementation.
I guess one might argue that this functionality should be unit tested
separately, but that kind of misses the completeness of the black box
test. I guess one solution is to make the necessary functions available
to the httpnit tests though otehr packages. Of course these tests would
not pick up fundamental errors in the third party, or seperate packages,
but that is another story ...
>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.
>
interesting. doesn't httpUnit sort of do this automatically when it
accesses the html generated from the template? If there were
velocity/rendering issues the correct html would not have been produced?
>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.
>
Right. This is one of the main things I am trying to address. I don't
want to spend lots of time writing httpUnit tests and then spend lots of
time re-writing them when the interface design changes. Some people
have recommended servlet level testing (with cactus, or ServletUnit) to
avoid the GUI dependency, but then the GUI is still not being tested.
In order to try and solve *all* my problems :-) I have started to
implement the system I described in my original mail. I will scan my
gui templates to generate outlines for my test classes and http-form
handlers, and then when my gui changes I can re-scan them and regenerate
the outlines. I guess the outlines would be better off as base classes
that the actual test and form handling implementations would extend, in
much the same way that torque generates base classes from a data
description. Update your data model and the base classes are adjusted
automatically ....
I guess ideally one would be able to specify the GUI components in XML
(as torque specifies its data model in XML), but since I have limited
resources I'm going to start with HTML template specification of the GUI
and see how far I can get.
CHEERS> SAM
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: An idea about HTML templates and Testing
Posted by "Jeffrey D. Brekke" <jb...@wi.rr.com>.
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: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
=====================================================================
Jeffrey D. Brekke jbrekke@wi.rr.com
Wisconsin, USA brekke@apache.org
ekkerbj@yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>