What I actually do is make an API in front of the web app to make an
abstraction and allow a user to do what he is supposed to do in term of actions.
That makes the distinction between validating the text against validating the
web app behavior when a user interact with the webapp.
For example a user could create a new job like the following.
jenkinsPage.createNewJob().setType(freestyleType).setName("toto").save()
This would click on the menu item "new job" and then select the type from the
radio button list, set toto in the text field that represents the job name and
create the job.
For repeatable objects, What I do when I have those kind of features is that I
look at how many instances there are when the user add a new one to then find
the new added html markup, then in my object that represents the repeatable, I
can set the proper search context and interact with the proper sub html
elements. For exemple :
job.addNewBuildStep(shellScriptType).setScript("... bash script goes here ...")
The addNewBuildStep find the current steps, click on the step to add, find the
newly added markup by grabbing again all the steps on the page but remove the
steps that were ther before it. You are then left with the newly added step
markup element that you can pass to a factory method of scriptType to create an
object that represents the specific settings for that type where it's search
context is limited to that markup.
A user wants to make interaction, everything "markup" related is handled by the
API. Making changes to the layout is then validated/handled by the API. Also,
if the text or the markup changes and you didnt't make an API to reflect what a
user can do on a page/section of page, alot more work will be involved to fix
them all where the functionnalities didn't really change but just the look of
it did.
I always feel like validating through finding the proper text is wrong in
regard to validating through the functionnalities a page provides. A user
typically doesn't want to validate that the proper text is there rather than
with some given settings the funcionnalities work as expected.
Richard Lavoie
> On 2014-03-15, at 18:15, oliver gondža <[email protected]> wrote:
>
>> On Sat, 15 Mar 2014 22:34:01 +0100, Richard Lavoie
>> <[email protected]> wrote:
>>
>> What about just changing the selector to rely on html markup instead of
>> actual text ?
>>
>> This will solve the issue altogether of the I18n problem.
>
> In this case probably yes, generally no. There are a lot of elements that are
> rather obscure to identify using markup so we rely on text labels quite often
> (repeatable elements for instance). Adding meaningful ids to Jenkins UI
> elements will have other benefits besides UI tests but I am not convinced it
> is a good idea (to avoid reading text labels). Verification is often based on
> reading text that is a subject of localization. We can probably rely
> exclusively on machine readable information like markup and REST API but then
> we no longer have acceptance tests from perspective of a human using web
> browser.
>
> --
> oliver
>
--
You received this message because you are subscribed to the Google Groups
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
