[Rspec-devel] Rspec/Test::Unit Integration

aslak hellesoy aslak.hellesoy at gmail.com
Fri Jul 7 01:34:30 EDT 2006


On 7/6/06, Brian Takita <brian.takita at gmail.com> wrote:
>
>
> > Have you tried test2spec?
> > http://rspec.rubyforge.org/tools/test2spec.html
>
>
> I have not tried test2spec yet. It does look interesting. It looks like it
> does its job very well.
> I would like to introduce it to my workplace, but going around and
> converting all of our tests into specs seems heavy handed. We could have a
> pilot project, but it would be nice to just have it work within the context
> of our existing tests and libraries.
>
> I was also looking at the converted test and defining helper methods inside
> setup seems a bit unintuitive.
> It seems strange to have to define your methods inside of the setup block.
> Can it be done inside context instead?
>

Currently not. Every spec runs in the context of a new instance of
ExecutionContext, and in order to be able to call any helper methods,
they also have to be defined on the current execution context object -
which is why it has to be done in setup.

If you have a lot of helper methods in your specs that's a smell of
complexity, so as long as things are not smelly, I think a couple or
three helpers in setup is ok.

> > When things are inside a Test::Unit::TestCase you still have to use
> > the Test::Unit runner, and you won't get the spec commandline goodies.
>
>
> I'm not too familiar with the command line tools you have now, but they do
> look interesting. These tools do seem like a very strong feature.
> Pardon me if I'm missing the point, but the tools can read contexts defined
> inside a Test::Unit::TestCase by only parsing the file.
>
> > Rails fixtures also work with RSpec on Rails.
>
>
> Unfortunetely it appears that you needed to duplicate code. If you want to
> do integration tests, you would need to hook it into RSpec, and the same
> goes for Selenium tests.
>

Integration test support in RSpec on Rails is high on the priority list.
I'd recommend using rails integration tests OR selenium/watir, but not
both. They sort of cover the same thing.

>
> > >From what I understand this patch allows you to use contexts inside
> > Test::Unit::TestCase classes.
> >
> > Are you trying to work on existing Test::Unit::TestCase classes and
> > keep them a mix of both test methods and contexts/specs?
>
>
> Probably not. It's just a proof of concept. I'll email you another patch
> with a "better" syntax.
>
> > If you really want to stick to the Test::Unit structure, how about this:
> >
> > require 'test/unit'
> > require 'spec'
> >
> > class MyTest < Test::Unit::TestCase
> >   def test_should_allow_shoulds_in_tests
> >     (1+2).should_equal 3
> >   end
> > end
>
>
> Thats cool. I'm glad you pointed that out.
>

If you're stuck with Test::Unit, why not just use Test::Unit?
(possibly with should_* as shown above).

I still don't see the benefits of being able to use the context and
specify keywords inside Test::Unit classes. How is this better than
'pure' Test::Unit?

I hear the 'smooth migration path' argument, but in order to be a
migration path I'd assume that some time down the road it would lead
to a RSpec-only codebase. But I don't see how this solution is leading
to that.

I don't mean to be negative - I just don't get it (yet) ;-)

Aslak

> > My point here is that using context and specify inside a
> > Test::Unit::TestCase doesn't really buy you that much. Sure, the
> > context/specify DSL looks nice, but the real value of this DSL (IMO)
> > is the integration with the spec command line and the ability to
> > output specdocs with --format specdoc.
> > When things are inside a Test::Unit::TestCase you still have to use
> > the Test::Unit runner, and you won't get the spec commandline goodies.
>
>
> Actually it does call runner.add_context(context). This makes it supportable
> by the tools, right?
>
> Thanks,
> Brian
>
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>
>


More information about the Rspec-devel mailing list