[Webtest] [dev] source cleanup?
Fri, 24 Sep 2004 11:10:16 +0200
> > I agree, remember we need that for site deployment.
> > It is more difficult to do since we have dependencies in the xml entity
> > defs.
> what about using xsl:document in the xslt rather than entities in
> the xml? Indeed the doctype with the entities is the
> cause of all the errors reported during the xslt transformation.
Does xsl:document remove the dependency?
> what about using the config to output in a "build dir"? I guess
> that user have their own webtests under source control
> too and it's wether for us neither for them a good practice to
> have output dirs between source dirs.
Hm, I guees there already is a "reports.dir" for that purpose.
We could override in our build from the calling build.xml.
> >> - doc/package-lists
> > I disagree. It is needed for the api-doc generation.
> It's used for offline javadoc generation that's right. But first:
> who is offline today? And second, it's out of date:
> half of the url are wrong and the listed packages don't
> correspond to what is currently used.
Who's not behind a firewall today :-) ?
Anyway, most important is that is works on the build machine.
If you know a way that works without the package lists
(but still produces the required links), go ahead.
> >>- move junit tests in a separate source folder and remove all
> > I disagree.
> why? It's a common usage on numerous great open source projects.
Aha. Any numerous great open source projects out there with a test coverage
over 90%? Moving tests away from the code is the first step into
What would be the benefit from moving them away?
> >>- use jsp for selftests instead of html generated from a servlet
> > I disagree.
> why? The jsp are easier to read and to maintain. Who uses freely
> servlets to generate html code today? Personnaly, I was
> quite discouraged when I wanted to made my first webtest
> "commitable" after having seen this servlet.
I agree that the current implementation of the FormTestServlet
is overloaded as it serves too many purposes at once. But this
doesn't mean that it is the wrong technology for the purpose.
JSP are sometimes easier to read, i.e. in the most simple cases.
They are certainly harder to maintain as they tend to
collect massive duplication as their number grows.
I'm happy to use static html for simple clicking tests.
I'm happy to use JSP for the simplest logic.
I'm happy to use plain Servlets when more logic is needed.
BTW: We use Servlets freely and generate html for a number of
web applications that run on our customer's sites,
serving literally millions of pages with
consistent look and behaviour. Maintenance effort is some orders of
magnitude lower than with all the templating approaches that
our customers have in other places.