[Rspec-devel] Adaptation of rpsec

Keith Hodges Keith.Hodges at warwick.ac.uk
Sat May 6 08:40:20 EDT 2006

David Chelimsky wrote:
> 1) "expect" and "dontWant" don't read as opposites to me. rspec uses
> should_be and should_not_be, which are more obvious opposites. So
> expressing it like this:
> expect(3).toBe(3);
> expect(5).toNotBe(5);
> or
> expect(5).notToBe(3);
Indeed I agonised over the wording for a while, I am open for 

I did implement the operator 'not' to allow that kind of wording, i.e: 

> would be more in keeping w/ rspec's approach, and more readable in my view.
> 2) Nested specifications. One of the pitfalls of xUnit frameworks is
> the tendency of developers to use inheritance to eliminate duplication
> in setting up test fixtures. Things become very difficult to grok -
> especially when there's a failure you're trying to understand.
Interesting, yes I have done it myself a lot, I have used inheritance a 
great deal, particularly when testing "the next version" while still 
needing the ability to test the previous version.
> We had some discussion of supporting hierarchies in rspec and more or
> less agreed not to for the time being for that very reason.
I am not sure that having an aggregation or tree structure for 
specifications is as difficult to manage as inheritance. I guess time 
will tell.
> 3) Multiple expectations per expression
> (expect(a).toBe(3).and(b).toBe(5))). I think this ends up more
> confusing than just expressing the expectations separately.
I can see your point particularly with that example in which the 
expectand is changed by the and(), perhaps that should not be allowed. I 
wanted to be able to specify things like I want A to be of class "foo" 
with value 5 in one expectation.
>  A key goal
> should be consistency in expression and to make things more readable.
> This would violate that consistency in my view. Also, what is the use
> of or()? Why would you want to allow for any variation in the result?
> That's just asking for bugs and headaches.
Oh? I included this on the basis that I would have thought that it would 
be more common in a specification to have a bit of flexibility 
specified. Such as "I expect this value to be a range of valid things".
> 4) The specify()/specified() structure feels a little funny. Can you
> move whatever is happening in specified() to specify()? So if there is
> a specification being described, wrap it up. Then begin a new one. It
Ah, this is kind of a legacy feature, I developed JSSpec to be used 
within tiddlywiki. In this environment  the result of each line is 
evaluated and displayed. This precluded the use of enclosures or  a {} 
or do-end construct to wrap the  specification.
> That's all for the moment. Feel free to respond if you so desire. And
> thanks again for doing this and sharing it with us.
> Cheers,
> David

thanks for the fairly immediate feedback to chew on


NEW Yahoo! Cars - sell your car and browse thousands of new and used cars online! http://uk.cars.yahoo.com/

More information about the Rspec-devel mailing list