David Kemp wrote:
I have just committed an extension to the command handler framework so
that assert, assertNot, verify, and verifyNot are all generated
automatically from no-arg getters. Previously it only worked with
single-arg getters.
As a result of this, I have now rewritten assertTitle,
assertAbsoluteLocation, assertAlert, assertConfirmation, and
assertPrompt as getTitle, getAbsoluteLocation, getConfirmation, and
getPrompt.
Great work, David!
Might you be able to retrospectively raise a JIRA issue for this work,
(if there isn't one already), so we can easily maintain the Release Notes.
As a consequence, we now have commands like assertNotTitle and
assertNotAbsoluteLocation etc.
Excellent! In some cases, though, it might read better to have the
negation at the end, e.g. assertTitleNot, assertAbsoluteLocationNot.
Could we register BOTH negated variants, ie. both prepended and appended?
Can someone please try this out in Konquerer and/or Safari?
It all seems to work fine in Konqueror.
Not sure what to do about assertSelected.
Currently you specify what you want to compare against (value, label,
index, or id) in the value field:
e.g.
assertSelected | foo | value=bar
This can easily be transformed into an isSelected(locator,
qualifier=expected) method, but this is a little limiting. e.g.
storeSelected would store true or false.
I think that's fine ... isn't that what storeVisible, storeTextPresent
etc would do, too?
Better might be getSelected([EMAIL PROTECTED]) so that you can store the
actual value rather than just true/false.
Asserts would then look like:
assertSelected | [EMAIL PROTECTED] | bar
Hmmm, that's a user-interface change though, isn't it?
This also needs to be generalized further to multi-selects. Maybe
something like:
assertSelected | [EMAIL PROTECTED] | one,two,three
How do we handle multi-valued selects now? (Looks). Ah, I see, they're
not supported in assertSelected, but there's a separate
assertSelectOptions command. Were you thinking of rolling
assertSelectOptions into assertSelected?
Not sure where you would throw in the pattern matching qualifiers like
regexp and exact.
Maybe PatternMatcher could be extended somehow to support a syntax like:
assertSelected | [EMAIL PROTECTED] | list{one,regexp:f[aeiou]o,exact:f*?}
Anyone got some better ideas?
I think we should leave the signature of assertSelected as-is. If this
means we can't auto-derive it from "getSelected", so be it.
As far as "getSelected" goes, how about:
getSelected(locator, attribute)
returns the value of <attribute> for the selected option
Not sure about best to handle multi-valued selects. Perhaps it's easier
to stick with separate commands?
--
cheers, MikeW http://www.dogbiscuit.org/mdub/
_______________________________________________
Selenium-devel mailing list
Selenium-devel@lists.public.thoughtworks.org
http://lists.public.thoughtworks.org/mailman/listinfo/selenium-devel
