[rspec-devel] [Proposed Refactoring] - Current ExampleSpace class subclasses Test::Unit::TestCase

[David Chelimsky]

On 8/22/07, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> On 8/23/07, David Chelimsky <dchelimsky at gmail.com> wrote:
> > On 8/22/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote:
> > >
> > > On Aug 22, 2007, at 3:02 PM, aslak hellesoy wrote:
> > >
> > > > On 8/22/07, Dan North <dan at tastapod.com> wrote:
> > > >> Hi Aslak.
> > > >>
> > > >> aslak hellesoy wrote:
> > > >>> On 8/21/07, Brian Takita <brian.takita at gmail.com> wrote:
> > > >>>
> > > >>>> This is a way to utilize Test::Unit in rspec.
> > > >>>>
> > > >>>> There are a number of BDD frameworks that utilize Test::Unit to
> > > >>>> create
> > > >>>> a simple implementation.
> > > >>>>
> > > >>>> This could also be a first step to using Test::Unit's runner.
> > > >>>>
> > > >> A similar conversation happened in the early days of jbehave about
> > > >> whether to use junit's runner. We decided to go with our own runner
> > > >> (like rspec did) because we wanted it to do other stuff (mostly
> > > >> lifecycle callbacks).
> > > >>> Using Test::Unit's runner might be compelling, but I don't know how
> > > >>> easy it will be to make it behave like today's RSpec. We have a
> > > >>> lot of
> > > >>> extra command line options, different output and so on. I'm not sure
> > > >>> what it takes to make it happen.
> > > >>>
> > > >> I don't think it would be too difficult to write an adapter to run
> > > >> under
> > > >> test::unit. Right now, the describe method captures a block of code -
> > > >> the description (aka context) - and the it method captures another
> > > >> block
> > > >> of code - the example. You can replace these methods as follows:
> > > >>
> > > >> - describe Sheep dynamically creates a class called SheepTest that
> > > >> extends a subclass of TestCase, then it executes its block to gather
> > > >> examples, by using a modified it() method as follows:
> > > >> - it "should baa" dynamically creates a method in SheepTest called
> > > >> test_should_baa that looks like this:
> > > >> cls.define_method :test_should_baa do
> > > >>     begin
> > > >>        alert_listeners(:starting)
> > > >>        run_describe_block_with_it_method_disabled # so helper methods
> > > >> are defined
> > > >>        run_the_actual_example_block
> > > >>        alert_listeners(:succeeded)
> > > >>     rescue
> > > >>        alert_listeners(:failed)
> > > >>        raise
> > > >>     end
> > > >> end
> > > >>
> > > >> - Any before(:each) or after(:each) blocks get added to lists inside
> > > >> SheepTest to be invoked by  boilerplate SheepTest#set_up/tear_down
> > > >> methods.
> > > >> - before :all and after :all would be more tricky, but they are
> > > >> discouraged anyway.
> > > >>
> > > >
> > > > It's more like the ! ruby methods. It's dangerous, there is a non
> > > > dangerous alternative and you should know precisely what you're doing.
> > > > (perhaps we should rename it before! to follow that convention).
> > >
> > > I always thought that that was a LISP/Scheme convention - the
> > > question mark signifying a boolean return value, and the exclamation
> > > point signifying an "unsafe" function - unsafe in the Haskell/
> > > functional way of thinking (i.e. change the state of an object).
> > > Obviously Ruby isn't a functional language, so I've always been a
> > > little bit curious as to what is considered "dangerous".
> >
> > I don't think of ! as dangerous.
>
> http://blog.segment7.net/articles/2007/08/15/david-black-explains-bang-methods

Guess stub! was a mistake :(

>
> > To me it means "do this to yourself."
> > When you say list.reject { ... } you get a new list back with the
> > appropriate items removed. When you say list.reject! { ... }, those
> > items are actually removed from the list you're sending the message
> > to. Make sense?
> >
> >
> > >
> > > Scott
> > >
> > >
> > > _______________________________________________
> > > rspec-devel mailing list
> > > rspec-devel at rubyforge.org
> > > http://rubyforge.org/mailman/listinfo/rspec-devel
> > >
> > _______________________________________________
> > rspec-devel mailing list
> > rspec-devel at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-devel
> >
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>