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. 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. 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. 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. Libraries and utilities have a different audience and their testing is perhaps better handled solely in unit and functional tests, but I cannot say so with any conviction. -- Posted via http://www.ruby-forum.com/. _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
