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. Richard Lavoie > On 2014-03-15, at 16:24, Ulli Hafner <[email protected]> wrote: > > Thank you very much! This project really is a good starting point for my > student projects. We can help to port existing tests or add new ones for > missing areas. > > I found the problem with the help of Oliver on my machine: the browser is > started with my German locale so the Jenkins driver is waiting forever that > „About Jenkins“ is appearing on the screen: on my system the text is „Über > Jenkins“… > Maybe we should start the browsers with the English locale (this will improve > the portability of all tests, too). > > Ulli > > >> Am 15.03.2014 um 03:30 schrieb Kohsuke Kawaguchi <[email protected]>: >> >> >> I've spent several hours working on the documentation of this. >> >> https://github.com/jenkinsci/acceptance-test-harness >> >> I'm still trying to make this work on Jenkins, and Ulli reported a failure >> to run, so there's still some rough edges, but I think it's making progress. >> >> My favorite addition is prelaunching Jenkins instance [2], which drastically >> reduces the time it takes to iteratively develop a test. >> >> >> [1] https://jenkins.ci.cloudbees.com/job/core/job/acceptance-test-harness/ >> [2] >> https://github.com/jenkinsci/acceptance-test-harness/blob/master/docs/PRELAUNCH.md >> >>> On 02/28/2014 10:38 AM, Kohsuke Kawaguchi wrote: >>> I've promoted our selenium test harness [1] a lot in the last few months on >>> my >>> trips to various places, as well as in Jenkins Scalability Summit. I see a >>> great >>> opportunity in this, in that: >>> >>> - when large users write their acceptance tests on the same format and >>> share >>> it in the community, it creates a larger pool of test cases that we can >>> reuse. >>> >>> - the harness acquired ability to launch complex fixtures (external >>> systems) >>> through docker, allowing us to test more interesting scenarios that are >>> hard to >>> do in the unit tests. For example, I'm not testing JIRA plugin with real >>> JIRA. >>> >>> - we want to start doing more non-functional tests, like creating a Jenkins >>> master with 100 slaves, put some load on it for a few hours and make sure it >>> works all right. >>> >>> Wherever I show it, I see people agree with the ideas. I talked to my >>> colleague >>> Vivek offline, and he is interested in helping me make this happen --- he >>> has >>> developed a plugin in the very early days, and he's well versed in Java and >>> Ruby! >>> >>> One of the common feedbacks I've heard from people during my pitch of this >>> effort is that this project being in Ruby creates a cognitive disconnect, >>> given >>> that Jenkins developers are primarily Java people. The toolchain involved in >>> running is also little bit alien to them, and so is the environment for >>> writing >>> tests. So I can see why there's the question of "why Ruby just in this >>> project?" >>> >>> I've been hesitent to spend time porting harness to Java, because it didn't >>> feel >>> like the best way to spend our precious time. Over time I think I've >>> managed to >>> learn enough of the Ruby hacking and the tooling, to be reasonably >>> productive >>> with it, too. But nonetheless I felt like it's always an option that I can >>> come >>> back to. >>> >>> But as Vivek and I were talking about implementing some missing >>> functionalities >>> to achieve these goals, I realized that once we start adding more code to >>> it, >>> it'll become very difficult to do the porting. So suddenly I started seeing >>> selenium-tests being in Ruby as a risk (to the potential adoption), and the >>> opportunity to correct it is now or never. >>> >>> So Vivek and I are trying the time-bounded approach to this problem; we are >>> going to spend one day (today) to try to port it over to Java. If at the >>> end of >>> the day we don't think it's doable, or if we hear back from the community >>> that >>> it's an insanity, we'll stand corrected and keep on the selenium-tests >>> project. >>> So please share your thoughts (and my apologies in advance that I didn't >>> float >>> this idea sooner in the list.) >>> >>> The repository where I'm doing this is >>> https://github.com/jenkinsci/acceptance-test-harness. The plan is to rewrite >>> page objects, step definitions, and JenkinsController in Java, swap Capybara >>> with WebDriver, but keep all the cucumber features intact. >>> >>> >>> [1] https://github.com/jenkinsci/selenium-tests >>> -- >>> Kohsuke Kawaguchi >>> >>> -- >>> 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/groups/opt_out. >> >> >> -- >> 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. > -- 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.
