See comments inline...
On 1/23/09 1:46 PM, James Byrne wrote:
Ben Mabey wrote:
So... I'm curious what people's thoughts are. When writing acceptance
tests how do you choose which tool is best for the job? I often hear
people complaining about the GWT syntax and they see no benefit of it
over the frameworks that provide contexts (i.e rspec, shoulda, etc).[1]
In what cases, if any, do you think the GWT gets in the way and how? In
particular, if you are writing an app or lib whose customers/users are
all developers do you still think there is value in the GWT syntax that
Cucumber provides?
My own experience is quite limited, but I did start out trying to get
what I desired done through TestUnit, then RSpec, then RSpec Story
Runner and finally Cucumber. In the end it was Cucumber that clarified
my approach for me, mainly by clearing away all (or at least most) of
the nitty gritty details of configuring and using the tool itself. I
found that, coming from a non OO programming background, that the degree
of mastery required of the other tools mentioned, together with the
effort I had to make to get the tool to behave as I wished (desires that
were often malformed by lack of understanding in any case), distracted
considerably from the task at hand, programming the application.
Interesting, thanks for sharing what your background is. I have seen
other developers who don't have a strong OO background struggle with the
concepts of isolation have a really hard time understanding how and why
to use rspec. However, they seem to love Cucumber and it makes total
sense to them.
I have progressed on my current project far, far more since discovering
Cucumber this past November than in all the time before. The
bifurcation between what and how seems far more natural to me with the
Cucumber features/step definitions file split than with the unified
expectation method/test steps of RSpec and the test method/assert
statements of TestUnit. Cucumber feature files just seem to permit one
to concentrate solely on "what" in the one case and then, with the
separate step definitions file, deal with the "how" in the other,
without crossing the line between the two.
Ahh.. that is a very good observation. When I write examples in rspec I
start out with the example description first (obviously) but then I like
to jump straight to my expectation. Meaning, I will say something like
"dog.should be_happy" before I have even created the dog object. I like
to do this for the same reason- I first write what I want and then I go
a line above and create the how/given. A lot of people complain about
the separation of code form story in plaintext features, but as you have
pointed out that separation can be a very good thing.
Given, When and Then seemed contrived and far too stiff to me to begin
with. However, I discovered that much of my initial discomfort arose
from too vague a conception of what is was that was desired. The
benefit of GWT stylistic conventions is that it really does make one
consider deeply where one is starting from, what one is actually trying
to accomplish, and how, exactly, does one tell if it has been
accomplished.
If this sort of self-analysis is so ingrained that one need not think of
it then GWT probably does not provide a measurable benefit. So, perhaps
deeply experienced developers and programmers might not get as much from
it as I have.
On the other hand, I have frequently discovered in myself a lamentable
tendency to believe that I understood what a problem was simply because
I wanted to believe and not because of any demonstrable evidence to that
effect. Sitting down and writing out what you believe to be the truth
often reveals the flaws in ones assumptions. The GWT litany seems to
provide a very useful, if formulaic, examination of exactly what one is
setting out to accomplish thereby sometimes raising the question of why
it needs to be done at all. I find that it thereby clears away much
that is irrelevant to the question at hand.
+1. I totally agree with this. When it is difficult for me to write
scenarios I find that the reason is that I fail to really understand
what I am trying to accomplish. By flushing the acceptance criteria out
in the GWT language I come out with a much better understanding of the
problem and know exactly where to begin.
I also hold to the opinion that when writing an end user application the
only testing that can be consider definitive is what is described as
integration or acceptance testing. I accept that there are pragmatic
reasons why, because of limited time and equipment resources, unit and
functional tests are viewed as attractive alternatives. But, that
should not blind one the the fact that they really are alternatives,
chosen because of environmental considerations and not because of
inherent superiority. The only test that means anything to an end user
is one that shows the application works as intended in the environment
it is deployed to.
So here is where I disagree with you. :) I do agree that all the user
cares about in the end is that the desired outcome is reached and the
business value is provided. So with that mindset features are the only
kind of tests a customer really cares about. Unit tests however are
more for the developer. They aid in design and provide much more
detailed documentation than the customer testes (acceptance tests). I
don't think that cucumber features help me design my objects that much
better unless I have focused object level examples telling me where the
pain points are in my design. Eventually the customer will be greatful
that you have unit tests (even if they don't know about them) because
they will help lower the maintenace of the project by encouraging better
design and providing tighter and more focused feedback on the smaller
parts of the system. IMHO, of course.
Thanks for the feedback,
Ben
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
