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.
