[LRUG] Writing readable feature tests with RSpec

[Andrew Premdas]

On 26 July 2014 11:10, Murray Steele <murray.steele at gmail.com> wrote:

>
> On 26 July 2014 01:24, Andrew Premdas <apremdas at gmail.com> wrote:
>
>> On 25 July 2014 11:46, Murray Steele <murray.steele at gmail.com> wrote:
>>
>>> I like cucumber because of how it makes me think about what the user
>>> journey I’m testing is actually about and for, but I dislike cucumber
>>> because I think the regexp matching for step definitions places an
>>> unnecessary burden on the developer.
>>>
>>
>> This is really unfortunate. The fact that regex's are there in Cucumber
>> means that you 'can' do all sorts of stupid things with them. If you do
>> that will be a burden. However it doesn't mean you should do this or have
>> to do this. 50% of my step definitions have no parameters at all, and I
>> suspect less than 3% have more then one parameter.
>>
>
> To be fair to cucumber this is how I ended up using cucumber in my last
> outings with it and it was much nicer to use.  I learned a lot about how to
> write acceptance/integration specs from doing cucumber the right way.
>
> We don't criticize Ruby for allowing us to write stupid code, but it seems
>> that we expect Cucumber to do more.
>>
>
> Sure.  I think a large part of the problem here is that well written
> application code exhibits different qualities than well-written test code.
>  For example duplication is usually bad in application code as it means a
> bug can surface in multiple places but only be fixed in one.  However in
> test-code lots of DRYing up can make the tests harder to read and for me
> readability of tests is one of the most important qualities.
>

I think its a little more subtle than that, and one of the reasons I prefer
using Cucumber to RSpec for this sort of thing is that Cucumber makes the
following a little more obvious.

When you are writing features you have two very seperate things that you
are doing. The first is writing code that translates the meaning of a
feature into a call that does something. The second thing is implementing
calls that do something. As an example if we take something simple like
signing in we might have

When I sign in
When Murray signs in
Given I am signed in
etc...

The mistake people make is to DRY up the translation. So in Cucumber they
make one step definition with horrible regex's to implement this. However
the only thing you need to dry up is the execution (the code that actually
signs you in). So when I Cuke I'm quite happy to have

When I sign in do
   sign_in as: @i

When Murray signs in
  sign_in as: "Murray"

Given I am signed in
   sign_in as: @i

... it really doesn't matter how many step definitions are like this

But there is only one sign_in helper method.

Using Cucumber 'properly' means thinking of step definitions as being
strictly translators who make calls. With RSpec getting this
differentiation is a little bit harder;  each rspec feature ends up doing
alot of different things.


>
> For all the different ways we can write bad cucumber, we can do the same
> things with rspec features.  The fact that we’re even writing articles
> about how to write rspec features in a (to me at least) clearer style
> suggests that there are plenty of rspec features out there written in
> styles that aren’t so useful.
>
>
I think its harder to write good rspec features. RSpec is designed to write
tests, and you have to jump through some hoops to make it do feature work.
For experts in RSpec these hoops might seem to have a lower cognitive load
than working with Cucumber, but I suspect that is as much not having
expertise in Cucumber and having expertise in RSpec, than the objective
suitability (if there can be such a thing) of each tool to do this job.

All best

Andrew

I think well written cucumber is a good tool, and I’d rather have well
> written cucumber on a project than badly written rspec features.  All else
> being equal though, I’ll reach for rspec features.
>

> Cheers,
>
> Murray
>
> _______________________________________________
> Chat mailing list
> Chat at lists.lrug.org
> Archives: http://lists.lrug.org/pipermail/chat-lrug.org
> Manage your subscription: http://lists.lrug.org/options.cgi/chat-lrug.org
> List info: http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>
>


-- 
------------------------
Andrew Premdas
blog.andrew.premdas.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20140726/11e5bcf5/attachment-0003.html>