[rspec-users] Test for a gem/plugin?

James Byrne lists at ruby-forum.com
Wed Dec 10 11:04:44 EST 2008


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/.


More information about the rspec-users mailing list