Salad? Gimme Steak. (Moving off Cucumber for acceptance tests)

How much longer until Steak gets a nifty DSL so it looks like Cucumber again, maybe they'll call it Zucchini this time.<p>Ruby seems to be playing with fire a little bit here, similar to the insanity that happened with Java and XML.<p>Java programs can't handle some edge case, program becomes configurable with XML, huge win. Then XML goes way too far, people start disliking XML, Java falls from grace.<p>Ruby programs are somewhat cumbersome, but Ruby, being fairly awesome, allows you to define a DSL. People write DSLs that make tasks easier, huge win. Then there are too many DSLs, people get tired of trying to figure out _another_ (groan) new DSL to do something they now know how to do in ruby.<p>Both start with this simple idea, flavor of the month type thing, that in the beginning is a huge win. After a while though both burn out. I think the saving grace for ruby is that people will just reimplement the DSL as a more straightforward ruby library.

My strategy for dealing with all these ruby testing fads is to just keep on plugging away with good old Test::Unit and avoid the churn all together. It takes about two minutes to teach somebody how to read asserts and then you're done.

I have a couple issues with Steak:<p>1. It seems to take something that's already pretty straightfoward (RSpec) and just adds a couple keywords.<p>2. You're writing code when you should be describing features. Trying to remember where to put an underscore or what should be a symbol makes it harder to focus on describing the feature.<p>3. It greek to any non-developer. If you tried e-mailing this to a product owner or a user they would ask why you're sending code samples.<p>I know you addressed #3 in your blog post but why did you decide to use Steak over RSpec alone? Do you have any issue ramping up new developers with the Steak syntax?

I've used cucumber for several years and love it. The author raises these issues:<p>a) Organization of steps in a huge project is hard.<p>b) Complex quoting is hard<p>c) Token links in e-mail are hard<p>d) Manual poking of background jobs is hard<p>As a Cucumber user I've run into some of these.<p>a) Step Organization: In large projects, this is indeed difficult. I would love an os x app that could search step definitions. On the other hand, Ack makes it fairly simple to find steps. Furthermore, you can always organize them into folders.<p>If you see cucumber steps as methods, the author is basically saying "having methods makes things hard because I don't know if someone has already written the method. Therefore, I have given up on methods and now write everything inline."<p>b) Quoting: Cucumber allows for multi-line step definitions<p>c): Token links in e-mail are hard: Not sure exactly what he's talking about. But check out <a href="http://github.com/bmabey/email-spec" rel="nofollow">http://github.com/bmabey/email-spec</a> which I helped write / solves e-mail issues for cucumber.<p>d) I have a step that just says "And the system processes jobs." In this step, I just run all the delayed jobs. It's not that hard.<p>To be fair, I haven't looked at steak very much, and am just going off of this blog post.

I like Steak, but the main reason for using Cucumber in the first place is to interface with your customers, or at least with people that understand the business side of things on a piece of software. Steak doesn't aim to, and won't replace that.

It's interesting. Are there any performance improvements?

yum... steak