Marc Guillemot wrote:
Hi Paul,
as you note, defining a login macro would do exactly what your customer
looks for. Nevertheless a macro makes only sense when it is reused
multiple times.
In your groovy example, could you imagine cases where the name of your
closure differs from the value of your reportAs attribute? If not,
perhaps could we imagine a way to notify the result listener that a
closure has been entered and that it should be displayed in the report
just like a macro call.
It is usually a method not a closure but it is sometimes a closure
invoke too. It might be possible to do it automatically but that
doesn't exactly correspond to how it is being used. The methods
are refactored for programmer/tester convenience to remove duplication
or for other purposes (we have multiple levels of DSL - one level
corresponds to the output of a third-party recording tool - we adapt
what it records onto WebTests API). The 'DSL' in some sense corresponds
to a subset of the programmer known methods. The reporting might even
be a simplified representation of the DSL.
To give an example:
customer-level DSL might have:
click 'Login'
test-level DSL might have:
clickByLabel 'Login'
clickById 'someId'
clickByXPath 'expression'
additional internal methods known by power users might be:
clickByXPathWithAjaxWait '...'
(made up example but you get the idea)
When reporting we usually don't want too many levels.
Customers just want high-level groupings, they might expand
that to see some intermediate groupings. They might expand that
to see the actual webtest form/page manipulation steps.
If we started introducing auto-named macros through this
they might become frustrated and confused.
So, we could go down the auto-generation path but we would need
some mechanism or convention to control when it was used.
The group idea was the "simplest idea that could work" approach
and I would be reasonably comfortable with it.
Paul.
Cheers,
Marc.
Paul King wrote:
I have a customer that would like to add some convention or extra
attribute for reporting of groups. They would like something like:
<group description="..." reportAs="login">
...
</group>
It is actually used within our DSLs in Groovy:
def login(...) {
ant.group(description:'...', reportAs:'login') {
...
}
}
The 'reportAs' or 'label' or 'info' attribute would appear in the
report in bold instead of the current step name of 'group'.
This would allow our DSLs to end up more naturally reflected
in the reports.
Does this sound like it would be of general interest?
Cheers, Paul.
P.S. we could also explore whether we could make macrodef's
or other steps/tasks be able to make use of such a feature.
_______________________________________________
WebTest mailing list
[email protected]
http://lists.canoo.com/mailman/listinfo/webtest
_______________________________________________
WebTest mailing list
[email protected]
http://lists.canoo.com/mailman/listinfo/webtest
