[Webtest] Name of step: emulateSetHiddenInputField
Sat, 20 May 2006 06:32:38 +1000
Except that all other setXXX, clickXXX steps correspond to the user
clicking on a link, button, checkbox, or typing in some text, etc.
There is NOTHING that the user could ever do to force changing
the hidden field directly. Nothing to click, type, no menu option etc.
Because of this we arguably shouldn't even have the step and we
would then require that users of WebTest keep putting in changes to
real browser does and change the hidden field indirectly.
But because we are pragmatic and like to please our users, we do
give them this option to bypass what a normal browser can do.
Anyone who uses this trick needs to know that because they are
bypassing normal browser behaviour that they are no longer testing
their complete application. They are bypassing an important
HTTP state information in to states that is not possible to
ever set for their application - changing their application
under test - and potentially having downstream tests which rely
on this. Its kind of like setting the wrong expectations on a
mock and then building up additional layers of tests which
rely on this mistake.
So, I think something which reminds the tester that they are
applying a trick is a good thing.
I definately don't want to drop the step. Even in places
a test into two pieces (kind of like an integration test
into a unit plus smaller integration test). If you have
several hidden fields (not suggesting its good style but
some frameworks give you this) then you can test that doing
various actions sets the hidden fields as you expect.
Then as a separate test you can check that invoking the
application with various forced values works as expected.
You can use techniques like pairwise testing (AKA all-pairs
or orthogonal array testing) on the hidden values. We have
also used JsUnit for the first step of this two step
sequence (we have partial integration of JsUnit with
WebTest so that you get the same reporting - I hope to
add it into the main distribution one day when I get
time to finish integration).
As a compromise what about keeping force but dropping the
emulate and Set parts.
I.e. emulateSetHiddenInputField -> forceHiddenInputField
And then we could also rename:
emulateSetInputFieldAttribute -> forceInputFieldAttribute
+1 from me? :-)
Dierk Koenig wrote:
> to me, the only thing that's special about setting a hidden field
> is that it's 'hidden'. Neither do I see that it is emulated nor forced in
> way that's different from other setXXX steps.
> I opt for 'setHiddenInputField'.
>> -----Original Message-----
>> From: email@example.com
>> [mailto:firstname.lastname@example.org]On Behalf Of Marc Guillemot
>> Sent: Freitag, 19. Mai 2006 5:40
>> To: email@example.com
>> Subject: Re: [Webtest] Name of step: emulateSetHiddenInputField
>> probably the best alternative until now... but I'm still not
>> fully satisfied
>>> What about forceXxx?
>>> Marc Guillemot wrote:
>>>> ok for the point: "hidden" is... hidden in the name of the step.
>>>> I'm not really happy with emulate, pseudo and simulate.
>> Perhaps fakeXxx?
>>>> Paul King wrote:
>>>>> Marc Guillemot wrote:
>>>>>> I'm quite unhappy with the name of the field
>>>>>> Why "emulate"? Why not simply setHiddenInputField?
>>>>> If the user could normally trigger this by using some action then
>>>>> we should drop the emulate. But this can never be triggered directly
>>>>> ugly name is probably a good thing.
>>>>> Alternatives: pseudoXXX, simulateXXX