On Mon, 26 Nov 2012, Kohsuke Kawaguchi wrote: > > Hi, > > Moving this conversations to [email protected]. > > Yes, what you are talking about is [1], which is an attempt to > define blackbox acceptance tests in a way that lets us test our > final deliverables (rpm, deb, etc.) It contains the page objects, > among other things. > > I think having a java library that defines page objects for Jenkins > is useful. Go for it!
When I first started working on the selenium-tests repo, I tried to come up
with some page-object abstractions that made sense but I just couldn't find
anything that I didn't find crappy. Some of the abstractions that I ended up
defining were more focused on logical objects (Job, Build, Slave, etc).
> There's also a conversation of adding another functionality (either
> in this plugin or another one) that exposes Groovy scripting console
> in a way that lets you verify side-effects that happen on the server
> more easily.
I'm not sure if you're alluding to hooking groovy-based validation into the
selenium-tests but I would caution against it. There be dragons! Such
functionality would start effectively breaking down the testing pyramid (unit,
integration, UI tests), and becomes a huge pain in the ass over time.
Integration testing to verify side effects of things internal to Jenkins, I'm
all for though :)
> And then maybe it's possible to run selenium-tests in JRuby so that
> we can run some Java-based selenium tests in the same environment,
> which allows you to leverage pluggable layers in the selenium-tests
> and VirtualBox integrations.
Ick, I'm not going to tell anybody that's volunteering to write tests how to do
it, but mixing different platforms is going to be a lot of work, even with
JRuby, it's no silver bullet.
Just my few cents :)
Cheers
- R. Tyler Croy
--------------------------------------
Code: https://github.com/rtyler
Chatter: https://twitter.com/agentdero
signature.asc
Description: Digital signature
