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.
