On Wed, 28 Nov 2012, Kohsuke Kawaguchi wrote: > On 11/27/2012 10:17 AM, R. Tyler Croy wrote: > >>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. > > Yes, I was alluding to it. > > Today, the way we make sure certain things actually happened is to > look for a specific log message in the console output. That makes me > nervous. > > So the ability to verify that certain things have happened in the > server by letting the test client execute some groovy script and get > the result back, I think it's an useful building block. > > Yes, the feature can be abused, I agree.
The way that we solve this at Lookout is we expose a couple of API end-points
that help answer specific questions instead of having something as open-ended
as Groovy scripting.
For example, a GET of /api/qa/user/<userid> would return a JSON version of the
User object, then our test would fetch that and check the user object has had
the necessary changes made to it.
IMO this approach would be solved either with the existing REST API or with
another plugin that exposes more internal Jenkins data.
- R. Tyler Croy
--------------------------------------
Code: https://github.com/rtyler
Chatter: https://twitter.com/agentdero
signature.asc
Description: Digital signature
