cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ovidiu Predescu <>
Subject Re: testing/performance framework for Cocoon
Date Mon, 24 Sep 2001 17:03:10 GMT
On Mon, 24 Sep 2001 09:43:34 +1000, Jeff Turner <> wrote:

> > This is part of the functionality I'm looking for. I also need some
> > rudimentary support for defining variables, so that values extracted
> > from one response document can be used later in the test. Ant
> > properties seem to do a good job of this.
> How could you do that in Ant?
> In Latka, you can set properties, and refer to them with ${..} notation,
> but I don't think you can define new vars during a test.

You cannot do this using an externally visible task, but in your Java
code you can set the values of properties. If you really want to do
it, you can even write a <set> task that sets the value of a property
(not that I want to do it ;-).

> > > Note that it doesn't use Ant. I suspect this is actually a good
> > > thing. Ant 1.x is not flexible enough to be easily repurposed as a
> > > http testing engine. This will apparently be fixed in Ant 2, which
> > > will be a generic "task execution engine", but for now, it's
> > > probably harder to turn Ant into something it's not, than to start
> > > again. For instance, there have been *many* submissions of an
> > > iterate, or <foreach> task:
> > 
> > As I looked at Ant, it appears to me the internal architecture is well
> > designed and could support the testing framework I think of. The only
> > problem I see is the usage of SAX1 API, which precludes one from using
> > XML namespaces. I think this problem can be fixed though, by doing the
> > appropriate changes within Ant, the code is very well localized. Other
> > than this issue, I don't see any reason why Ant would not be a good
> > framework to support this testing framework.
> > 
> > Would you please elaborate on your reasons why Ant's engine would not
> > provide a good testing framework?
> Grumble.. no-one's free to make wild unsubstantiated claims these
> days.. ;) It rather depends on how far you want to go with the
> "scripting" side of things. Eg, it is not possible to reassign variables
> in Ant, so the following might not be possible:
> <iterate name="i" start="0" end="100" increment="1">
>     <spawn threads="${i}">
>       <url-post href="${url}/test/echo"
>          content="contents/sample.xml"/>
>       </spawn>
> </iterate>
> Other than that, I have no specific reasons why Ant couldn't be used,
> only a general warning that this is not ordinary Ant usage. Ant was
> designed to be a declarative build tool. The ant-dev people have
> resisted all attempts to turn Ant into a procedural XML scripting
> language. This shows up in various ways, like the non-reassignable
> variables, lack of boolean evaluation, and almost no function calling
> (<antcall> is very frowned upon).

Yes, I saw that...

> However, if it can all be done in extension tasks, great :)

I think it can be done.

> > I believe that no matter what route we go, we should not exclude other
> > options from being used. If somebody feels httpunit is the framework
> > to use to test a particular feature, it should be possible to use it.
> Okay, you've convinced me ;) If you use Ant, it would be simple to
> include Bernhard Huber's httpunit tests in a <junit> task.

I'll try to integrate all of them together and post a patch.

> For the <iterate>, you might want to use one of the many contributed
> (and rejected) on ant-dev. There have been other useful
> submitted-and-rejected tasks like that. If needed, I can contribute some
> basic tasks (online, mimetype, well formed XML, valid XML).

I'll post some code very soon so you can take a look at it and comment
on the ideas. Please feel free to contribute ideas and code to it!

Ovidiu Predescu <> (inside HP's firewall only) (my SourceForge page) (GNU, Emacs, other stuff)

To unsubscribe, e-mail:
For additional commands, email:

View raw message