> Having said that, the pluggable architecture of JMeter may allow for
> "Clever but Slow" Components to be made that are useful for Functional
> Testing, but should not be installed in performance tests?
The two areas can be related - quite often, performance tests must test
correctness and for complex bugs that only show up under a certain load.
After all, what good is it if the page rendered but a key field was
missing?
Using your example Jordi...
> (eg using ugly __regexFunction syntax to send a hidden parameter from
> last response. -
> ${__regexFunction(<input type='hidden' name='someID'
> value='(.*)'>,$1$,1,,,)}
> Note also how brittle this is (case-sensitive, expects single-quotes
> and exact whitespace,and doesn't recognize comments or other false
> positives)
...
> (in example above, you would expect a good HTTP Functional test app to
> get hidden parameters with some much simpler function -
> eg getHiddenParameter("someID")
> - you would also expect this to have parsed the HTML so it can eg
> ignore comments or other unwanted text that simple req exp would
match.)
If a bug caused the hidden parameter's value to mysteriously disappear
(value="" ) when the number of concurrent users went past 1000, JMeter
would be one of the few ways to testing that particular regression.
I agree the regex. assertion isn't ideal - maybe an "HTMLParser
Assertion", maybe with XPath query support, to parse the page would be
better. I sincerely hope JMeter continues in the direction of providing
richer primitives to make functional testing easier - it's *almost* a
great functional test tool too.
With regards,
Sonam Chauhan
--
Corporate Express Australia Ltd.
Phone: +61-2-9335-0725, Fax: 9335-0753, Email: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
