Seems that the latest changes broke a lot of tests: https://jenkins.ci.cloudbees.com/job/core/job/acceptance-test-harness/lastCompletedBuild/testReport/
Am 17.03.2014 um 19:13 schrieb Kohsuke Kawaguchi <[email protected]>: > > There's no downside to adding micro-formats, CSS class names, and so on to > make HTML pages more machine readable in the core, so we should be doing that > whenever we find them. So I just added the version attribute to <h1> in that > spirit. > > I should also note that the primary machine readable endpoints on Jenkins are > REST APIs, and for example, the version information of Jenkins is quite > easily available in the response HTTP header. > > Also, adding those micro-formats won't really help this test harness any time > soon as we need to be able to test existing releases of Jenkins. > > > In the mean time, looks like Ulli made the change to launch browser in the > English locale, so we are unblocked. > > On 03/15/2014 06:48 PM, Richard Lavoie wrote: >> 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 >>>> >> > > > -- > Kohsuke Kawaguchi | CloudBees, Inc. | http://cloudbees.com/ > Try Jenkins Enterprise, our professional version of Jenkins > > -- > 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.
signature.asc
Description: Message signed with OpenPGP using GPGMail
