And instead of relying on the text I prefer adding css classes that represents the ui component. Solves the problem of i18n .
Richard Lavoie > On 2014-03-15, at 21:45, Richard Lavoie <[email protected]> wrote: > > 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.
