[rspec-devel] Splitting up the APIs

Brian Takita brian.takita at gmail.com
Sat Nov 25 17:34:41 EST 2006


On 11/25/06, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
>
> On 11/25/06, Luke Redpath <contact at lukeredpath.co.uk> wrote:
> >
> > As I said on Rick's blog comments, I think this would be a good idea, so
> a
> > big +1.
> >
>
> I'm not completely convinced it's a good idea to split things up. The
> build system would become more complex (circular dependencies if we
> continue to use rspec).
>
> What exactly would be the benefits that we don't have today?


You may be right...
For expectations one can:
require 'spec/expectations'

and for mocks:
require 'spec/mocks'

The only benefit that I can think of is it would draw more attention to each
specific module of rspec.

Aslak
>
> > It would be nice to maintain some kind of meta-package (rspec) that
> installs
> > all of them - I don't know how easy or difficult that is with rubygems,
> I've
> > never done it.


Its very easy. Just call add_dependency in the Gem definition.

>
> > Cheers
> > Luke
> >
> >
> > On 25 Nov 2006, at 20:07, Brian Takita wrote:
> > On 11/25/06, David Chelimsky <dchelimsky at gmail.com> wrote:
> > > On 11/25/06, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> > > > Many people don't realise that RSpec can be used from within
> > > > Test::Unit like this:
> > > >
> > > > require 'test/unit'
> > > > require 'rubygems'
> > > > require 'spec'
> > > >
> > > > class SpecTest < Test::Unit::TestCase
> > > >   def test_hello_should_be_of_length_four
> > > >     "hello".length.should_be 4
> > > >   end
> > > > end
> > > >
> > > > Christian (http://tinyurl.com/sr665) and Rick
> > > > (http://tinyurl.com/y736tq) have taken the ideas they like from
> RSpec,
> > > > reimplemented it in their own way (NIH) and released it to the
> public.
> > > > Competition is good - as long as it brings something new to the
> table.
> > > > I'm not sure what these two clones do better though.
> > > >
> > > > Anyway, I think now is a good time to split RSpec up in three parts:
> > > >
> > > > * should_expectations.gem
> > > > * rspec_context.gem
> > > > * rspec_mock.gem
> > >
> > > For consistency, could we call the first one rspec_expectations.gem?
> > >
> > > Otherwise I like this idea a lot.
> >
> > +1
> >
> > > > Hopefully this will reduce people's urge to replicate RSpec's ideas
> -
> > > > because they can pick what they need.
> > > >
> > > > Of course, it's possible to cherry-pick what you need from RSpec in
> > > > its current form, but people have a strange tendency to feel uneasy
> > > > when they only use parts of a library. It's weird.
> > > >
> > > > Aslak
> > > > _______________________________________________
> > > > 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
> >
> > _______________________________________________
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20061125/e3b10d89/attachment.html 


More information about the rspec-devel mailing list