Matt Wynne <[EMAIL PROTECTED]> writes: > On 21 Nov 2008, at 18:15, James Byrne wrote: > >> As I work with Rails TestUnit tests I am reconsidering how to use >> cucumber features. It seems to me that it might be best to have a >> coherent view of how to arrange my test suites before I get much >> further >> into this. Now, so far I have considered three possibilities: >> >> 1. Use features exclusively. Create a feature file for each model, one >> for each controller and possibly an additional one for those views >> that >> need separate tests. Name then with the nomenclature x_model.feature, >> x_model_controller.feature and where desired, x_view.feature >> >> 2. Use features exclusively. Create one feature file for each >> non-decomposable piece of system functionality. Test models, >> controllers and views within each feature file. >> >> 3. Use features and RSpec. Well, is that not what I am doing with >> features alone? Or, are their cases when testing with RSpec spec >> files >> are a better choice than a features scenario? >> >> 4. Use features and TestUnit. Naaahhh... >> >> 5. Some other way of which I have not considered. >> >> In the interest of enlightenment and from a desire to avoid >> unnecessary >> back tracking as my project develops, what do experienced >> practitioners >> suggest as the favoured way of arranging test suites. >> >> Yes, I have done the goggle thing but I really have not found anything >> terribly useful about organizing tests specifically for Rails. > > No doubt it's (3) for me. It's all about working from the outside in.
Agreed. > Cucumber is for Acceptance Testing, and those acceptance tests should > not be cluttered up with edge cases. They should ideally be readable > by your stakeholders / customers. I disagree with the part about edge cases. Acceptance Tests are about defining and verifying business value, and edge cases are supremely valuable to businesses. What happens when an ATM user tries to withdraw $1 more than he has available in his account? Lately I've been putting more and more stuff into ATs. I'm finding it valuable to keep tests for domain logic separate from plain ol unit tests...meaning that my Account object may be tested mostly with Cucumber, but helper objects such as a stats aggregator will be spec'd with code-level examples. Pat _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
