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.
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.
Equally, when you hit something complicated in a class that's likely
to be pulled in different directions by different features, it's
responsible to start writing unit tests for it. Whether you choose to
use RSpec or Test::Unit for those unit tests is really up to you.
Those unit tests can then be used by the next programmer who comes
along to change that class to satisfy another feature as well as yours.
I am absolutely loving doing BDD from the outside in. Driving early
changes from Cucumber acceptance tests means you have so much more
space within which to refactor (not being hemmed in my unit tests /
mocks) as the design emerges during those first few iterations. It's
been nothing short of a revelation for me.
cheers,
Matt
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
