Watch Ben Mabey's slides and talk at Ruby Conf on outside in development with Cucumber. It positions rspec and cucumber properly
_______________________________________________
rspec-users mailing list
rspec...@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
--
John Goodsen RADSoft / Better Software Faster
jgoo...@radsoft.com Lean/Agile/XP/Scrum Coaching and Training
http://www.radsoft.com Ruby on Rails and Java Solutions
_______________________________________________
rspec-users mailing list
rspec...@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
On 2010-04-21 4:29 PM, Ed Howland wrote:
Yes, but if you have 2 step_definition files and they each have a
matching regex for a step, how do you distinguish them when running
cucumber?
You don't. You can have only one matching reg ex. The step definition would need to make a decision about which path of execution to follow and call the appropriate method.Thanks,
Ed
Peace,
Phillip
--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+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/cukes?hl=en.
On Wed, Apr 21, 2010 at 5:49 PM, Phillip Koebbe <philli...@gmail.com> wrote:On 2010-04-21 4:29 PM, Ed Howland wrote:
Yes, but if you have 2 step_definition files and they each have a
matching regex for a step, how do you distinguish them when running
cucumber?
I may be wrong, but I don't think Matt was suggesting a single step behaving two different ways. Rather, I think the idea is that a step which is a higher level description affords you more choices in how to implement it, including skipping the UI entirely. If you use a declarative style in your scenarios, you don't have to be tied down to clicking certain things or filling in certain fields, for example.I'm not sure exactly how having the same step behaving in two different ways would come into play, at least for this discussion, as it seems easy enough to just write two different steps.Greg
You don't. You can have only one matching reg ex. The step definition would need to make a decision about which path of execution to follow and call the appropriate method.Thanks,
Ed
Peace,
Phillip
--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+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/cukes?hl=en.
--
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+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/cukes?hl=en.
Cucumber features are the best tool I know of for capturing requirements from my customer. RSpec specs are the best tool I know of for communicating intent and gauging code quality among the developer team.
I'm not sure how exactly you're quantifying a 90/10 or 80/20 split. I would expect that there would be a lot of overlap in coverage. That is, any given line of code is likely to have some cucumber and some rspec coverage. Personally I shoot for 100% RSpec coverage, and Cucumber is based entirely on what my customer wants. If we discuss a new feature or bug fix and they feel I know exactly what they're talking about and don't need a cucumber test for it, I don't write the cucumber test. Cukes are for teasing out requirements, which is most important when there's domain complexity that I don't understand, because I'm a programmer and not a domain expert. Every line of code I write gets RSpec coverage. That's how I personally feel confident that my code does what I think it does, and also helps me keep my dependencies under control.
It's true that you can change out all the underlying code and cucumber tests still pass. But you should be able to change out a lot of code and have your specs still pass, as well. If you're changing the API then some specs might no longer be valid, or need to be moved, or whatever. That's just a part of refactoring. Although to be honest I think focused specs help me refactor more than other people, because I take really small steps when I refactor. When most people "refactor" they tear out a bunch of shit and see if it still works.
Cucumber tests tend to take longer because they're written at a much higher level. That requires more setup, and more steps through the codebase. For that reason, Cucumber isn't particularly good at giving me rapid feedback. I want feedback in 10 seconds rather than 10 minutes.
The best mantra I have for using Cucumber & RSpec in harmony is, "RSpec lets me know my code works right, Cucumber lets me know my code is doing the right work."
I am in agreement with Mike and Pat here. As the folks I met at GLRB
explained to me, this was meant to increase productivity.
As soon as
the Cucumber features pass, you were done.
They might write some
corner case unit tests in RSpec. I think that is a little dangerous.
You'd have to be careful to write failure mode features. Those might
not be specified by the customer.
And I agree that the API emerges
from the rapid feedback loop that RSpec gives you. I also take very
small steps when writing and also when refactoring. Changing the whole
API has never occurred with me, usually it's small changes to the UI.
I do however think that domain level and full stack tests are an
appropriate use for Cucumber. In my current code, it's just some gems.
I'd like to write some domain level stuff for them. But I can't figure
out how to do that.
On Thu, Apr 22, 2010 at 12:14 PM, Ed Howland <ed.ho...@gmail.com> wrote:I am in agreement with Mike and Pat here. As the folks I met at GLRB
explained to me, this was meant to increase productivity.
Writing things that are unnecessary increase productivity. To that extent I agree with that statement. I like to minimize writing pointless examples that drive nothing, and increase the cost of maintenance over time.
I'll jump in here as I was one of the guys who presented a shift in my testing strategies at the Great Lakes Ruby Bash.
To give some context, I've built projects that were very focused on isolation tests that used Rspec and Mocks to assert behavior. I do think there is merit in using BDD as a code-design tool, however I have also maintained large test suites that had more historical context than regression value. I consider this inside-out testing. Developing/Testing at the unit level and then bubbling out to an Acceptance test.
I've been subtly migrating to what I consider outside-in testing, starting with Acceptance tests and then moving to a unit level if necessary. And as a result I've felt much better about the codebases (including the tests). Although I was getting a bit uneasy since I haven't heard of other developers experiencing similar pain points. Talking with a few developers at the Great Lakes Ruby Bash was really refreshing because not only did it sound like they had similar pains, but they were going down the same path I was.
I was one of the guys who did a lightning talk on a library I'm working on (Harvested, a Ruby API wrapper for Harvest http://github.com/zmoazeni/harvested). And I do have a 90/10 split in Acceptance vs Unit with I'm cool with. I wasn't throwing out those numbers as what you should shoot for, but just anecdotal experience.
I recognize that I may be criticized for writing untested code or that I'm disagreeing with BDD/TDD. I'm don't think I am. I feel I've gone way too far on the side of testing, and after reflecting on my experiences with past projects feeling the pendulum swinging back towards a healthy balance.
Some specific opinions I have are: I don't test Controllers or Views or Rails-DSL validations (e.g. validates_presence_of, validates_uniqueness_of). I do test "interesting validations", and instead of testing "interesting controller actions" I prefer to refactor that so the controller is very minimalist. The same goes for views, I pull away anything that looks "interesting" in a view. This is totally subjective, so I don't have a great way to clarify what I mean by "interesting".
I don't disagree with mocks, but I would rather have a "boxed functional test" (sorry running out of language here) that test how multiple objects behave together and use mocks/stubs to form the boundaries of the tests.
Hopefully this doesn't come across as another post of "I don't see the point of testing", or "Mocks are silly". Additionally, I'm a bit nervous posting these thoughts to an audience that are most likely going to disagree with this strategy. So I would welcome any support along with critiques on these ideas.