Russell Gold wrote:
>
> At 06:07 PM 6/29/2001 +0100, Jari Worsley wrote:
> >- by making HttpWebResponse public, you can give it nonsense for the
> >target and URL (1st and 2nd params), then give it the HttpURLConnection,
> >and get back an HttpWebResponse object, allowing calls like getText(),
> >getForms(), etc...
>
> Or we can specialize it to make a CactusWebResponse - it would be cleaner
> and shouldn't take a lot of work.
yes you could, although at first glance I would only need
HttpWebResponse to be declared a public class, and the constructor
either public, or at least protected so it can be overridden from
outside the package. Is there any reason the class and constructor are
declared as they are rather than public?
Jari
>
> We should talk some more about this. You have identified two specific
> useful ways to use the two together. I would be interested more in your
> ideas for model 2 testing. The tricky part there of course is that there
> is often a fair bit of coupling between the two, but you might be able to
> fake out the servlet to test the JSP in Cactus, and I see no reason that
> you could not do the same with the servlet, assuming that it is
> sufficiently well factored.
I have been talking more with some guys at work about this, and have
ideas taking shape :)
Typical anatomy of a request:
client makes request ->
1 action/Controller works with Model objects and DoesSomething :) ->
2 page build, depending on what resource you are forwarding to (servlet,
page etc), you take some
more action and PutJavaBeansInPage ->
3. then forward to some resource, eg. Servlet or JSP (which is , after
all, a Servlet).
Using HttpUnit I can test steps 1,2 and 3.
Using Cactus I can easily test steps 1 and 2.
Now, using a server side setUp, then you can write a test that puts
dummy data into the various JSP scopes, to allow you to test step 3 in
isolation.
I think this would be immensely useful for both unit testing, and to
provide a framework to allow parallel development of JSP pages with the
action code (all that is required is a "contract" between step 2 and 3 -
which I'm working on ;).
You could use automated tests with ant, and you could also provide
"tests" that can be run from a browser, so that a JSP author can start
working either in parallel or even _before_ the earlier steps have been
taken.
so using the ServletRedirector of cactus you could have calls like
<a
href="http://somehost:8080/test/ServletRedirector?params&testname=TestRegistrationPage1";
/>
which could open the results of the test in a new window - allowing a
JSP author to test their page for things that can't be picked up in an
automated test, like how does the page look when you use someone with a
name that is 60 characters long? or a description that is the full size
allowed in the database? or an image that may be too big ? etc.
JSPContract
===========
- thinking about this, the problem with Servlet and JSP development in
general, is that we use an untyped "bucket" to pass all our values
around. We have no typesafe API.
Imagine the following in a defence or telecoms scenario
someone - "write a class with a method to return some text please"
me - "ok, what's the API"
someone - "i'm going to pass you one HashMap with Strings for keys,
storing objects of type Object. Is that generic enough for you? "
me - "bunch of arse, no, bog off and come back with a proper typed API".
- yet in web development that untyped mapping of keys to Objects is all
we have.
If you were to have an API like the following:
public interface ServletContract
{
public ParameterInfo[] getParameterInfo();
public AttributeInfo[] getAttributeInfo();
}
public interface AttributeInfo
{
public String getName();
public Class getType();
public int getScope();
public boolean isRequired();
public void setRequired(boolean value);
public Object getValue(ServletRequest request);
}
and similar for Parameters - note there's probably overlap between this
and some of the tag library API's - not surprising given that tags can
declare an API for scriptlets in the page to use. This is just declaring
an API for the whole page.
You can then describe a page in a typed way by saying what Attributes it
expects, and you can test against it, and you can provide dummy
implementations, and perhaps loveliest of all...
- you know the feeling when you have a 10 page process, but it's teh
last JSP page that you are now debugging/creating, you know how much of
a pain it is to set up the test data/ test scripts using actions? Well,
if you have all I've described above, it means you would be able to test
that 10th page in isolation by writing a unit test to test that page in
isolation. :)
Going further
==============
It may be possible to automate collection of test data to a
ServletContract interface, perhaps integrating with JXUnit (Vincent, you
were asking how JXunit might work with Cactus :) - that would allow you
to do things like:
- get JSP authors to vary simple XML files of dummy data for the JSP
test phase, and write new cases like the LongName example, or
NameWithIllegal characters etc.
- generate forms to collect data for a test according to the
ServletContract
- get THE CLIENT to generate test data ! :)
So what do you guys think? These are all my thoughts so far on testing
of JSP under Model 2. I will have a go tomorrow on knocking up some code
for the contract part - a couple of us are quite excited at the thought
of trying to bring some rigour to JSP authoring, some type safety, and
some structure to the non-existant API :)
who knows, perhaps we could even get struts using this type of unit
testing? ;)
Jari
As an aside:
- given that a new instance is created for each test, rather for each
TestCase, doesn't that "break" the JUnit API a little? Perhaps we should
store an instance of a ServletTestCase so that the constructor is called
only once? Or is that not how JUnit is supposed to work? i.e. are you
supposed to rely on the setUp and tearDown methods and not rely on the
constructor at all?
--
Jari Worsley
Senior Programmer
Hyperlink Interactive Ltd
