http://rubygems.org/gems/steak
Steak claims to be a minimal solution for acceptance BDD in Ruby, so don't expect a long list of features in this announcement. Almost all maintenance since the first released version has been about making sure everything works with different versions of RSpec, Rails and other related gems. In this time, Steak has become the most popular NoCukes solution. So, instead of a list of features, I'll try to summarize the rationale behind Steak:
**Acceptance BDD is lovely**
Thanks to projects like Webrat and Capybara, writing end-to-end, integration tests that interact with your webapp like a user would do, is really easy (and nice). Acceptance BDD is probably the most useful tool to verify the correctness of an application, which allows more aggressive refactoring and re-architecting when needed. It also enables an Outside-In development approach and sets the development tempo, which helps to keep focus and flow.
**Some teams are fully technical**
If everyone in the team speaks Ruby (e.g. when you develop your own product), then the most efficient way to communicate within the team is through Ruby code. There is no point in adding an extra layer of indirection and ambiguity.
**User stories can be a great communication tool, but there are others**
Software development is largely a communication problem and user stories are helpful in that regard. However, alternatives like diagrams, mock-ups or prototypes can be as useful (or even more in some circumstances). However there's no better communication tool than **Working Software**. Your tools should help you get to working software as soon as possible.
**You can still write user stories, and then acceptance specs**
Admitting that well-written, succinct user stories can be helpful, what is exactly the point of making them executable tests? Because of their double purpose, features used as tests are worse user stories than regular user stories and worse acceptance tests than regular acceptance tests. Why not just write user stories and let developers write separated Ruby specs from those stories?
**I don't want my clients to write features**
There is an urban legend that some clients write their own features without any technical help. Even if it's true, I don't really want my clients to do that. Features describe *solutions* and clients have been proven terrible with solutions. They are experts in the *problem* domain and we, developers, are supposed to be the experts in turning problems into software solutions. Allowing clients (or users) to dictate how the application should behave is the perfect recipe for failure.
**Acceptance BDD is lovely**
I already mentioned this one, right?
Cheers!
-- Luismi Cavallé
I'm glad to announce that the first stable release of Steak is out!