[rspec-users] Test for a gem/plugin?
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:
>> When /authentication by authlogic/ do
>> #TODO: Find out how to test for a loaded gem within an application
> 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 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.
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
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
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
When /user logs in/ do
# If a user signs on then they do it here
When /user signs on/ do
When "user logs in"
When /user "(.*)" is authenticated/ do |u|
# We use Authlogic for authentication so just test that gem is loaded
Posted via http://www.ruby-forum.com/.
More information about the rspec-users