Ashley Moran wrote: > > Then you already have the name to verify if you want to display a > personalised message. (On the other hand, putting too much data in > the steps gets cumbersome; I tend to write them more like this: > > Scenario: A known user signs in successfully > Given I am a registered user > When I sign on with the correct credentials > Then I should see a sign in success message > > Even if internally I call out to steps more like the ones you wrote as > examples. Hope that doesn't muddy the waters though.
I believe that I am gaining some insight into how this is all meant to pull together. One of the difficulties I face is that different people evidently have significantly different philosophies about how and what to test (surprise, surprise, surprise!). As I am coming at this from the pov of someone who has had no prior experience with this approach, and whose training in it to date has been entirely theoretical in nature, I find this somewhat confusing. At the moment I tend to see cucumber features as my sole method of testing, an approach that I realize is not favoured by many. I began learning cucumber by writing a set of fairly low level functional tests following the template generated by cucumber. Now, based on the advice I have received here, I am trying a much smaller scale approach and generating a few very high level features. However, in the back of my mind I still consider that eventually I will specify much of the implementation detail, model attributes, data normalization routines, input limits, and so forth as feature steps somewhere. Experience will eventually teach me whether that approach is sustainable or not. I presently have in mind two distinct types of tests/features that I wish to represent. The first is the end user type of feature writing which conforms generally to the analysis of system requirements. The second set of features will be more like functional tests, that exercise the implementation details. My expression of the second type of features, the functional tests, are probably what is generating the greatest controversy. Some practitioners evidently see BDD features more or less as a pure analytical tool. They expect that functional and unit tests will be conducted mostly in a "traditional" manner, via test unit or rspec or similar testing framework. With this approach there is no need, or desire, that features elaborate great detail regarding implementation since that is done elsewhere. The dichotomy between feature steps and step definitions is another point of confusion for me. Take your reference to "if internally I call out to steps more like the ones you wrote." Does this refer to feature "Steps" or to step definition "Steps". I suspect the latter. In that case one can imagine that step definitions become rather more elaborate structures. Some step definitions perhaps even assume the appearance and role of rspec specs and have only a remotely dependent relationship to any feature step. It is in these obscure details that much of my confusion arises. Perhaps I have inferred your meaning correctly, perhaps I have totally misunderstood it. Regardless of which is true, doubt remains. -- Posted via http://www.ruby-forum.com/. _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
