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

Brian Takita brian.takita at gmail.com
Fri Jul 7 02:35:14 EDT 2006


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

You get more coverage with selenium/watir, particularly if you are doing
alot of custom javascript. I assume Rails Integration Tests (I havn't used
it myself), is faster to run than selenium, however. I bet the tests are
also easier to write.

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

My kneejerk reaction is not to agree with you here. Helper methods seems
modular and is a powerful tool against duplication.

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 agree. I've been converted. :) Please see the thread RSpec Extension
Patch.

Thanks,
Brian Takita


On 7/6/06, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
>
> 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
> >
> >
> _______________________________________________
> 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/20060706/54e43650/attachment.html 


More information about the Rspec-devel mailing list