Matt Wynne wrote: > On 9 Dec 2008, at 19:06, James Byrne wrote: > >> should >> >> When /authentication by authlogic/ do >> #TODO: Find out how to test for a loaded gem within an application >> end > > If you're working at the level of Cucumber features, I would stay well > away from implementation details like the particular technology you're > using for authentication. >
The features for this simply say something along the lines of: Scenario: Application has known users Given that the application has users When the user signs on Then the user is authenticated > Remember this is called Behaviour Driven Development[1] for a reason. > You're focussing on specifying the desired *behaviour* of the system. > How you chose to satisfy the user's need for that behaviour is an > entirely separate matter. Nonetheless, in the step definitions I must test the behaviour in a fashion which first drives and then confirms the implementation details. If the chosen implementation depends upon a third party plugin or gem then surely one should test for its provision? What is the alternative? Write tests to test that gems behaviour? Does that not violate TDD/BDD standard of only testing your own code? > > A large benefit of having Acceptance Tests, IMO, is that you could > radically change your implementation under the hood, such as switching > to a different authentication mechanism, and the features would still > be valid. You might have to code up some of your steps a little > differently, but as long as the users want the same thing from the > system, the features should not have to change in the slightest. > If the implementation changed then the step definitions must change to suit, must they not? One is, in the end, only testing what one actually does or wishes done. I do not see how in this case any implementation change would necessitate revising the features given above. If we were implementing our own authentication system then clearly more features or scenarios might be specified but the existing ones need not change. > [1]http://dannorth.net/introducing-bdd Read, re-read, and re-re-read. Nonetheless, it is possible to become dogmatic over such things. There is a considerable, and growing, body of opinion that so-called acceptance testing is suitable for many, possibly, all levels of application implementation. That the key to understanding when to use AT really lies in a flexible interpretation of the role of user. This is, as has been pointed out to me many times, an evolving art. The imaginary end user of any non-trivial application is actually an assemblage of disparate roles, many of which consciously do not overlap. Some of those users are the system administrators which tend to the day to day background maintenance tasks, some of which are automated and some of which are not. Some of the application users are, in truth, the implementors themselves. Not all features are of concern to all users/roles. Why should some users be denied the use of features and BDD as a tool for their own concerns simply because they are writing the code? It seems to me an artificial, and logically insupportable, distinction to make. While I am still a novice with much of this specific technology (TDD/BDD/Ruby/Rails) I have had a lot of experience, much of it bad, with overly rigid, and often misinformed, interpretation and employment of design methodologies. The quest for the silver bullet has led many teams down methodological dead ends, whereas a more flexible use of the same tool might have produced a beneficial outcome. What I have come up with is this, for now: When /has known users/ do # If we have known users then they must be stored somewhere my_user = User.new end When /user logs in/ do # If a user signs on then they do it here visits login_path end When /user signs on/ do When "user logs in" end When /user "(.*)" is authenticated/ do |u| # We use Authlogic for authentication so just test that gem is loaded assert defined?("Authlogic") end -- Posted via http://www.ruby-forum.com/. _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
