[rspec-users] Noob question

Korny Sietsma korny at sietsma.com
Thu Apr 30 00:37:30 EDT 2009


We did think about using JRuby to write data through the domain -
unfortunately it looked fiddly, especially as there are quite a few
things our ruby code wants to do that the domain doesn't cover.

For example, mass deleting data - in the domain, almost everything is
soft-deleted, and everything generates audit logs; in our tests, we
want do disable constraints and then delete everything in the
underlying tables, with no auditing.

Mostly, though, we started with really simple stuff that was easier to
do in ruby, and as usual things grew as we went along.  Moving to
using the real domain might be something we tackle as a refactoring at
a later date.  Also some parts of our database are legacy stuff that
doesn't really have a good domain layer - it'd be good to add one, but
it's a big chunk of work

I should throw in a quick plug here - the ruby sequel library (
http://sequel.rubyforge.org/ ) , despite having a sucky name, is
*great* for this sort of thing - manipulating tables, one-off
migration scripts, and the like.  If you need to manipulate data, but
don't want a full ORM, give it a look.

- Korny

On Thu, Apr 30, 2009 at 2:22 PM, Ben Mabey <ben at benmabey.com> wrote:
> Korny Sietsma wrote:
>>
>> We are actively debating this very topic :)
>>
>> For most stuff, we create data through the UI.
>>
>> We have a "Before" block that prunes the database back to a known
>> state before each scenario, using the ruby 'sequel' library.  It's
>> pretty fast, but it does mean we have to be careful in our selenium,
>> that we wait for the database as seen by the app to catch up with the
>> database session committed by the ruby code.
>>
>> And then our scenarios have stuff like "Given a top-level node called
>> "Foo" exists" - which creates the node via selenium.
>>
>> However there are some areas where this is just too slow, and we have
>> created some 'Given' steps that use ruby-sequel code that build up
>> data directly in the database.  This does mean duplicating some of our
>> Java domain in the ruby code, but it seemed to be a pragmatic solution
>> to the problem.
>>
>
> Have you considered running Cucumber with JRuby so you can leverage your
> Java code to insert records into the DB?  Just an idea.
>>
>> Currently we are debating whether to make more 'Given' steps directly
>> push data into the database - there are pros and cons either way;
>> using the UI gives us more confidence in our app (and less fragility
>> if our domain changes) and requires less code (we can reuse 'when'
>> steps from some scenarios as 'given' steps for others) but it's slower
>> - and the accumulated effect of slow builds can be terrible.
>>
>
> As far as the confidence aspect goes, it seems that you should gain enough
> confidence by having Cucumber fill out each form once then insert the data
> directly the other times.  That is at least how I approach things in webrat
> world.  But you are right about all of the trade-offs and that is why I am
> curious on how you are solving them.  Thanks for sharing!
>
> -Ben
>>
>> On Thu, Apr 30, 2009 at 9:32 AM, Ben Mabey <ben at benmabey.com> wrote:
>>
>>>
>>> Korny Sietsma wrote:
>>>
>>>>
>>>> True, but cucumber is useful for lots of different kinds of projects.
>>>> I'm currently using it to build a java webapp, so I don't need much
>>>> beyond cucumber, selenium, and selenium-client.
>>>>
>>>>
>>>
>>> I'm curious, with your current setup do you insert data directly into
>>> your
>>> database (i.e. in Given steps) or do you always use the selenium to enter
>>> in
>>> data.  Meaning, if you needed a user to exist so you could have them log
>>> in.. do you use ActiveRecord, or something similar, to create the user or
>>> do
>>> you use the webforms to create the user?  Also, how do you handle
>>> cleaning
>>> the database after each scenario?  Sorry, for the questions, but I'm
>>> curious
>>> how you've solved these problems when using Cucumber to test a non-ruby
>>> webapp.
>>>
>>> Thanks,
>>> Ben
>>>
>>>
>>>
>>>>
>>>> But agreed, if I was in rails-land (sigh) then I'd want webrat and
>>>> rspec-rails.
>>>>
>>>> - Korny
>>>> p.s. I'm aware webrat works without rails, but when I looked it didn't
>>>> seem a big boost for our kind of app.
>>>>
>>>> On Wed, Apr 29, 2009 at 10:42 PM, Chris Flipse <cflipse at gmail.com>
>>>> wrote:
>>>>
>>>>
>>>>>
>>>>> On Wed, Apr 29, 2009 at 7:42 AM, Korny Sietsma <korny at sietsma.com>
>>>>> wrote:
>>>>>
>>>>>
>>>>>>
>>>>>> Presumably you only need these if you are *building* cucumber?
>>>>>>
>>>>>> If you just want to use cucumber, it should be as simple as "gem
>>>>>> install cucumber", and it should get all the other dependencies.  On
>>>>>> my machine it seemed to install treetop, polyglot, and presumably a
>>>>>> few others - but I don't have rspec-rails nor webrat.
>>>>>>
>>>>>>
>>>>>
>>>>> rspec(-rails) and webrat aren't actually *required* by Cucumber -- you
>>>>> can
>>>>> use it without them, which is why they're not force-installed.
>>>>>  However,
>>>>> nearly every example you're going to find of Cucumber run against a
>>>>> rails
>>>>> app is going to be using webrat and rspec-rails ...
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> // anything worth taking seriously is worth making fun of
>>>>> // http://blog.devcaffeine.com/
>>>>>
>>>>> _______________________________________________
>>>>> rspec-users mailing list
>>>>> rspec-users at rubyforge.org
>>>>> http://rubyforge.org/mailman/listinfo/rspec-users
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>> _______________________________________________
>>> rspec-users mailing list
>>> rspec-users at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/rspec-users
>>>
>>>
>>
>>
>>
>>
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>



-- 
Kornelis Sietsma  korny at my surname dot com
"Every jumbled pile of person has a thinking part
that wonders what the part that isn't thinking
isn't thinking of"


More information about the rspec-users mailing list