>> - list of all step definitions (he needs to know those or otherwise every >> line of the feature will need to have a step def) > Have a read of this: http://elabs.se/blog/15-you-re-cuking-it-wrong
Yeah. I agree with that. I already use business terminology instead of techy. It does make the difference. I guess we just have to make sure we do not abuse it though (reuse as many step defs as possible, add new as necessary). > It's an interesting perspective on how some people approach Cucumber and how > it could be better used. I think you might be better off (and will get better > specs) if you show him the basic syntax and let him write them naturally. I'll give it a shot. Is there a way to list all the step_def from Cucumber to use as a reference? > If you try to force him into the mindset of your pre-defined steps, chances > are he's not going to document his ideas / requirements, he's just going to > try to visualise buttons and links. Yeah, I guess I meant to say how to balance here. >> - the speed of running specs (if it'll take 20 mins, I just won't run those) >> locally > You can get around this by using tags to select which scenarios to run / > exclude during your development cycles (see > https://github.com/cucumber/cucumber/wiki/tags) and then take advantage of > remote CI using something like TestPilot (http://testpilot.me/ — built by our > very own Ivan Vanderbyl!) to reduce your wait time. Awesome to know about the TestPilot! Thanks. Running locally is a must to me. Probably I can get around with @WIP tags or so and rely on CI for the rest. -- You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en.
