Sometimes the tests fail due to the fact that the file path-element.hpi has 0 Bytes file size. Is this plug-in installed differently that the plugins under test? Or can we present that if we package that file in the project?
Ulli Am 18.03.2014 um 13:30 schrieb Ulli Hafner <[email protected]>: > 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
