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.
