On 24 Nov 2008, at 18:29, Pat Maddox wrote:
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.
Yep. Agreed, you put it better than I could.
I am freaking people out at work because I seem to have practically
stopped writing unit tests, but I'm still certain that I don't lift a
finger without some automated test to force me into it. I'm just
finding that ATs give me a much bigger lever in terms of how much code
they drive out with a single test.
I have a feeling that people who've developed with FIT / JUnit must
have been through this loop before. Any war stories out there?
cheers,
Matt
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
