Here's an idea relevant to this discussion that came up last week when
I did a talk on Cucumber to ScotRUG.
Paul Wilson was describing how he used to use Fit, back in the day,
for testing at different levels in the stack rather than just for end-
to-end tests. The idea was to surface the tests at the same customer-
facing level, but steer them at the *appropriate* level in the stack,
depending on what was being tested.
So for example in the canonical problem of roles with different access
rights to a system, you could write the nice readable tabulated test
in Cucumber, but instead of running that cuke against the whole stack,
stepping through the login form etc, you could just run it against
whatever class is responsible for managing roles.
In order for this to work, you'd need to write the Cukes in a
declarative style, avoiding too much detail about exactly how you'd
carry out the step. This allows the same step to be run against the
whole stack or a focussed piece of the system instead. I tend to think
now that this is just good practice anyway.
This isn't something I've tried myself, but I imagine it means you'd
still get the benefit of customer-readable tests that validate the
behaviour of the system, but running potentially much faster than if
they were end-to-end tests. I can see a disadvantage that it could
make the test code more complex and confusing. You'd obviously still
need a few end-to-end tests in order to make sure the whole thing
still wired up together.
On a team with good customer-developer trust, I'd probably just use
RSpec for these kind of tests, but it's interesting to try thinking
about cucumber as The Place where business rules are surfaced.
Anyone tried doing anything like this?
On 20 Apr 2010, at 19:33, Ed Howland wrote:
Please forgive the x-post.
I just got back from the Great Lakes Ruby Bash. They had several good
presentations, two specific to BDD and Cucumber. I also talked to
several CEOs and devs afterwards, and the overall takeaway I gathered
was a shift to less RSpec and more Cucumber. Some people even claimed
a 90/10 split (cukes/specs) on current projects.
This was surorising to me and not at all how I worked up to this
point. I was more 20/80. I usually cuked a feature, then spec'ed the
code to make the cuke work. Each release had some new features and
specs for all the underlying code. Apparently, the feeling is that you
should do all your main thrusts with Cucumber and use RSpec for edge
cases. The theory is that you can change out all the underlying code
and the cukes still pass.
What is the communities consensus on this?
Cheers,
Ed
Ed Howland
http://greenprogrammer.wordpress.com
http://twitter.com/ed_howland
--
You received this message because you are subscribed to the Google
Groups "Cukes" group.
To post to this group, send email to cu...@googlegroups.com.
To unsubscribe from this group, send email to cukes+unsubscr...@googlegroups.com
.
For more options, visit this group at http://groups.google.com/group/cukes?hl=en
.
cheers,
Matt
http://mattwynne.net
+447974 430184
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
