[Rspec-devel] volunteers to prove out experiment

aslak hellesoy aslak.hellesoy at gmail.com
Wed Sep 6 01:53:05 EDT 2006


On 9/6/06, David Chelimsky <dchelimsky at gmail.com> wrote:
> On 9/5/06, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> > On 9/5/06, David Chelimsky <dchelimsky at gmail.com> wrote:
> > > All,
> > >
> > > I've created a branch with the modules and directories restructured to
> > > reflect three distinct modules:
> > >
> > > Spec::Expectations
> > > Spec::Mocks
> > > Spec::Runner
> > >
> > > Will the brave among you (with a little time on your hands - just a
> > > little) please check out the branch, build and install the gem and let
> > > me know if you run into any problems?
> > >
> > > svn co svn://rubyforge.org/var/svn/rspec/branches/modularized
> > > cd modularized
> > > rake gem
> > > gem install pkg/rspec-0.6.4.gem
> > >
> > > I'd like to merge this to the trunk as soon as possible to minimize
> > > the merge pain, but I want to make sure I'm not missing anything
> > > glariing.
> > >
> >
> > As mentioned in a separate mail, I think it's fine to merge this back to trunk.
> >
> > There is still some work to be done though.
> >
> > First, I'd love to see module/class names be modified to reflect the
> > file structure. We can do this once back on trunk.
>
> This is already done to some extent. There are now three separate
> modules as described above. What else did you have in mind?
>

spec/expectations/helper/have_helper.rb contains class Spec::HaveHelper.

They don't match. It's very deep. We could move the file one up and
change the module hierarchy so we get:

spec/expectations/have_helper.rb contains class Spec::Expectations::HaveHelper.

This is still kind of deep. Now that things are split and will stand
on their own feet perhaps we should think of real standalone names for
these libraries? That would allow one more shortening of depth.
Example:

should/have_helper.rb contains class Should::HaveHelper.

The expectations project could be called should(!). -Both the gem and
the namespace. Just an idea.

> > Second, we should modify the build so that the tests for each sub
> > library is run individually, to ensure there are no hidden cyclic
> > dependencies. I assume:
> >
> > (see this in monospaced font)
> > Runner->Mocks->Expectations
> >   |                   ^
> >   |                   |
> >   +-----------------+
>
> Why should there be even these dependencies? The specs will rely on
> all three, but I think they can be completely independent with the
> exception that if you just "require 'spec'" you'll get all three
> included.
>
> >
> > Again, this can be done on trunk. We should even consider having
> > separate Rakefiles for each sub project. That would be the cleanest.
>
> That would be OK as long as we can have a single Rakefile that will
> spawn all three. I don't want to have to build all three separately
> every time.
>

Sure.

> > We should package these as 3 independent gems, possibly with
> > independent versioning schemes similar to the way it's done in Rails.
> > I'm thinking 3 gems for now, possibly 4 when we start writing a more
> > gwt style runner:
> >
> > Runner becomes rspec.gem
> > Mocks becomes rspec-mocks.gem (which we may EOL later)
> > Expectations becomes rspec-expectations.gem
> > A new gwt runner could become rbehave(?).gem or rspec-gwt.gem
>
> If Dan is on board for rbehave, I think we should use that. I'll see
> where he is on his own rbehave project.
>
> David
>
> >
> > Thoughts?
> >
> > Aslak
> >
> > > Thanks,
> > > David
> > > _______________________________________________
> > > 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
>


More information about the Rspec-devel mailing list