Hey this reminds me of an old PullRequest :) https://github.com/jenkinsci/jenkins/pull/546
On 17.03.2014, at 18:34, Kohsuke Kawaguchi <[email protected]> wrote: > > Over the weekend, I've added code to the acceptance test harness so that it > can upload plugins from where the test runs, as opposed to download plugins > from the community update center. > > During the interactive test development and individual test execution from > IDE, you normally run Jenkins under test on the same machine you run tests, > so this is a lot faster. > > I've set this mechanism on by default, but it can be disabled with a custom > binding declaration of "uploadPlugins = false" in the wiring config file. See > [1] for more details of how to configure these things. > > > The actual download mechanism reuses Maven. > > > [1] > https://github.com/jenkinsci/acceptance-test-harness/blob/master/docs/WIRING.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.
