[rspec-devel] Good idea / bad idea? Scenario ... Same as

Ruy Asan ruyasan at gmail.com
Thu Feb 12 00:32:25 EST 2009


This seems like one of those things people smarter then I have already  
thought of and if it's not already included in cuke there is probably  
a good reason why...

I have some scenarios here which are quite similar to one-another, and  
differ in only a couple of ways.  For example,  we have scenarios that  
describe our invite system - it's somewhat similar to the gmail beta,  
in that people have a limited number of invites to give out. By  
default each invitation can only be used once, but we allow the  
possibility for multiple use invites which can be used to sign up  
multiple people (they are specifically meant for posting on your blog,  
the forums you frequent, etc)

So we have 2 scenarios:

1) Issuing an external invitation
2) Issuing an external invitation for multiple uses

For your reference, here's the first one:

(I am omitting some background which defines who Sally is)

Scenario: Issuing an external invitation
	Given I am "Sally"
	And I am filling in an invitation form
	
	When I fill in "email" with "mike at example.com"
	And I submit the invitation form
	
	Then I should see an external invitation has been created for "mike at example.com 
"
	And an email notification should have been sent to "mike at example.com"
	And my invitation count should have changed to 9

So far so good...

Now for defining the second one, I have a few options.

I could just state it in full:

Scenario: Issuing an external invitation for multiple uses
	Given I am "Sally"
	And I am filling in an invitation form
	
	When I fill in "email" with "mike at example.com"
	And I fill in "uses" with "3"
	And I submit the invitation form
	
	Then I should see an external invitation has been created for "mike at example.com 
"
	And an email notification should have been sent to "mike at example.com"
	And my invitation count should have changed to 7

However, I really don't like this at all. I have to read the whole  
damn thing only to realize it's basically the same as the last one  
with a few changes. The fact that it looks the same might lead me to  
belive there is only one difference instead of two. In general,  
throwing a lot of repetitive information in a way that is not easily  
susceptible to a "mental diff" is an excelent way to ensure the  
information wont' be read carefully and.

An alternative is to use scenario tables:

Scenario: Issuing an external invitation
	Given I am "Sally"
	And I am filling in an invitation form
	
	When I fill in "email" with "mike at example.com"
	And I fill in "uses" with "1"
	And I submit the invitation form
	
	Then I should see an external invitation has been created for "mike at example.com 
"
	# NOTE: even though mike at example.com is a known email we are still  
treating this as an external invitaiton
	And an email notification should have been sent to "mike at example.com"
	And my invitation count should have changed to 9

More Examples:
	| Invitation Uses | Final Invitation Count 	|
	| 3				  | 7						|

I don't like this either... I have to add an extra When step which  
shouldn't even be there (the form's "uses" field defaults to 1) and it  
really isn't clear what More Examples is referring to here (I'm  
guessing this is also why scenario tables are getting phased out in  
favor of scenario outlines)

And yeah, it's also possible to write this out using scenario  
outlines... but then the whole thing just reads much more mechanical  
then it has to... and it's all hooked up to a table with a measily 2  
rows. It's an ok workaround I guess, but it is far from ideal.


So, here's what I would REALLY like to do:


Scenario: Issuing external invitation for multiple uses
	Same as "Issuing an external invitation"
	But before I submit the invitation form, I fill in "uses" with "3"
	And instead of my invitation count should have changed to 9, my  
invitation count should have changed to 7

I really like this because this is EXACTLY how I would explain the  
multiple-use invitation scenario to another human being.

I understand it would be a very bad idea to use this to refer to  
scenarios at any great distance or in amounts greater then one can  
reasonably keep in our puny short term memories, but hey, it's never  
been the ruby way to withhold any great amount of rope from you, with  
which you can hang yourself with ;)

The syntax is fairly simple and predictable:

But (before|after|instead of) <step name>, <new step name>

This could probably just be defined as a normal step def... the only  
really new functionality would be "Same as"

Do y'all think this is a reasonable thing to try and implement?

If yes, are there any implementation mechanisms I could abuse to get  
it up and running with minimal effort?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/rspec-devel/attachments/20090211/4b95ec93/attachment.html>


More information about the rspec-devel mailing list