[Rspec-devel] Adaptation of rpsec

David Chelimsky dchelimsky at gmail.com
Sat May 6 08:16:13 EDT 2006


Hi Keith,

Thanks for doing this. It's a great start. Here are some initial
reactions to the things that you chose to do differently from rspec.
Keep in mind that these are MY opinions and I don't expect you to
change anything on my account. But please also keep in mind that I got
interested w/ BDD and rspec because they begin to solve very specific
problems that I've experienced over years of using xUnit frameworks.

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);

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.

We had some discussion of supporting hierarchies in rspec and more or
less agreed not to for the time being for that very reason.

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

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
looks like you need to indicate the end of a specification for
nesting, but I already expressed my concern about nesting. I guess you
would have to do the same thing when closing the context, so maybe
it's best the way it is already.

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




On 5/6/06, Keith Hodges <Keith.Hodges at warwick.ac.uk> wrote:
> Hello,
>
> I have been working on an adaptation of rpsec in javascript. My code may
> be a bit ropey but I think idea has some merit:
>
> I have included an example spec below.
>
> I use the word "expect" or "dontWant" to start sentences. I think that
> this may be more portable than the rspec approach since I didn't want to
> add methods to all objects in javascript.
>
> I love the ability to test more than one thing at once
> expect( a,b,c ).toBe( 3 ).or().toBe(5)
>
> Specifications may be nested and supply setUp/tearDown for their
> children. This gives the spec a tree structure and allows fixtures to be
> branched in order to specify alternative use paths.
>
> Any feedback/comments/etc would be welcomed.
>
> For code examples etc:
> http://www.warwick.ac.uk/~tuspam/js_spec/
>
> Keith
>
> =======================
>
> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"><html><head>
> <meta http-equiv="Content-Type" content="text/html;charset=utf-8" >
> <title>Test Something</title>
> <script type="text/javascript"
> src="include/InheritanceFramework.js"></script>
> <script type="text/javascript" src="include/JSspec.js"></script>
> </head>
> <body>
> <H1>Specification Testing in Javascript</H1>
> <script>
> context('defines the overall behaviour suite at the first level')
>     specify('begin a specification')
>         expect(1).toBe(1)
>         dontWant(1).toBe(2)
>     specified()
>     specify('strings compared as strings')
>         expect('2+2').toBe('2+2')
>     specified()
>     specify('demo multiple expectands and tests')
>         expect( 2,1+1,0.5 + 1.5, (4/2) ).toBe( 2 )
>         expect( [ 1, 1+1, 1+2 ] ).toBe( [1,2,3] )
>     specified()
>     specify('that items should be empty')
>         expect( {} , [], "" ).toBeEmpty()
>     specified()
>     specify('inclusion demo')
>         expect( [1,2,3] ).toInclude( 2,3 )
>         expect( "hello world" ).toInclude( "hello" , 'world' )
>         dontWant( "hello world" ).toInclude( "hellpo"  )
>     specified()
>     specify('regex demo')
>         expect( "hello world" ).toMatch( /HE.../i , /Lo/i )
>     specified()
>     specify('toRaise behaviour')
> ///        expect( "blah" ).toRaise('Foo')
> ///        expect( "blah" ).eval().toRaise('Foo')
>         expect( "blah" ).eval().toRaise('ReferenceError')
>         expect( "blah"
> ).eval().toRaise('ReferenceError').or().toRaise('Foo')
>     specified()
>     specify('logical ops')
>         a= 1;
>         expect(a).toBe(1)
>         expect(a).not().toBe(2)
>         dontWant(a).toBe(2)
>         expect(a).toBe(1).or().toBe(2)
>         expect(a).toBe(2).or().toBe(1)
>         expect(a).toBe(1).and(a*2).toBe(2)
>         expect(a).not().toBe(2).or().toBe(1)
>     specified()
>     /*nesting specifications with alternative naming convention (define
> is equiv to specify)
>        F is a default fixture provided by the framework*/
>     define('nested spec at 2nd level with cascaded setups').
>         setUp= function() { F.a= 1 }
>         define('specification at the 3rd level').
>             setUp= function() { F.a = F.a + 2 }
>             define('further nesting, now at 4th level' ).setUp=
> function() { F.a = F.a + 4 }
>                 expect( F.a ).toBe( 3 )
>                 specify('specification at 5th level, 3 setUps cascaded')
>                     expect( F.a ).toBe( 7 )
>                 specified()
>             defined()
>         defined()
>         specify('specifications at 3rd level, one setUp only')
>             expect( F.a ).toBe( 1 )
>         specified()
>     defined()
> context.writeDisplay()
> </script>
> </body>
>
>
>
>
>
>
>
> ___________________________________________________________
> Switch an email account to Yahoo! Mail, you could win FIFA World Cup tickets. http://uk.mail.yahoo.com
>
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>



More information about the Rspec-devel mailing list