Rails - Jun 2006 - testcase_setup_and_teardown_with_blocks (aka "The plugin with the very long name")

Hey all,

I got annoyed recently that I couldn''t specifiy multiple chunks of
test setup and teardown code that get executed for each test. You''re
currently limited to just one setup method (unless I''m much mistaken).
Anyway, I just wrapped up my solution in a plugin. The answer: use
blocks!

  class Test::Unit::TestCase
    # This is overridden by the subclass and will not be called
    def setup
    end

    # This is overridden by the subclass and will not be called
    def teardown
    end
  end

  class PersonTest < Test::Unit::TestCase
    # This overrides the method in the superclass
    def setup
    end

    # This overrides the method in the superclass
    def teardown
    end

    # Only the setup and teardown methods in this class will be called
    def test_name
    end
  end

Becomes ...

  class Test::Unit::TestCase
    setup do
    end

    teardown do
    end
  end

  class PersonTest < Test::Unit::TestCase
    setup do
    end

    teardown do
    end

    def test_name
    end
  end

It plays nicely with fixtures and should be completely backwards
compatible with existing code that uses setup and teardown methods.

Install with script/plugin install
http://svn.viney.net.nz/things/rails/plugins/testcase_setup_and_teardown_with_blocks

If anyone can come up with a better name for the plugin please do suggest it!

-Jonathan.

It might be helpful if you explain why you felt the pain that led to
creation of this plugin.

On 6/10/06, Jonathan Viney <jonathan.viney@gmail.com>
wrote:
> Hey all,
>
> I got annoyed recently that I couldn''t specifiy multiple chunks of
> test setup and teardown code that get executed for each test.
You''re
> currently limited to just one setup method (unless I''m much
mistaken).
> Anyway, I just wrapped up my solution in a plugin. The answer: use
> blocks!
>
>   class Test::Unit::TestCase
>     # This is overridden by the subclass and will not be called
>     def setup
>     end
>
>     # This is overridden by the subclass and will not be called
>     def teardown
>     end
>   end
>
>   class PersonTest < Test::Unit::TestCase
>     # This overrides the method in the superclass
>     def setup
>     end
>
>     # This overrides the method in the superclass
>     def teardown
>     end
>
>     # Only the setup and teardown methods in this class will be called
>     def test_name
>     end
>   end
>
> Becomes ...
>
>   class Test::Unit::TestCase
>     setup do
>     end
>
>     teardown do
>     end
>   end
>
>   class PersonTest < Test::Unit::TestCase
>     setup do
>     end
>
>     teardown do
>     end
>
>     def test_name
>     end
>   end
>
> It plays nicely with fixtures and should be completely backwards
> compatible with existing code that uses setup and teardown methods.
>
> Install with script/plugin install
>
http://svn.viney.net.nz/things/rails/plugins/testcase_setup_and_teardown_with_blocks
>
> If anyone can come up with a better name for the plugin please do suggest
it!
>
> -Jonathan.
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

SImple :). I wanted to define setup/teardown code in test_helper.rb as
well as the test files themselves. I also have another plugin that
will want to add bits of setup/teardown code and this makes it very
easy.

In my opinion this is actually a weekness in Test::Unit. Rails already
hacks around it to make fixtures work by aliasing setup/teardown
methods when you define your own method. This just takes it one step
further.

Has anyone else come up against this problem? How did you solve it?

-Jonathan.

On 6/11/06, Obie Fernandez <obiefernandez@gmail.com>
wrote:
> It might be helpful if you explain why you felt the pain that led to
> creation of this plugin.
>
> On 6/10/06, Jonathan Viney <jonathan.viney@gmail.com> wrote:
> > Hey all,
> >
> > I got annoyed recently that I couldn''t specifiy multiple
chunks of
> > test setup and teardown code that get executed for each test.
You''re
> > currently limited to just one setup method (unless I''m much
mistaken).
> > Anyway, I just wrapped up my solution in a plugin. The answer: use
> > blocks!
> >
> >   class Test::Unit::TestCase
> >     # This is overridden by the subclass and will not be called
> >     def setup
> >     end
> >
> >     # This is overridden by the subclass and will not be called
> >     def teardown
> >     end
> >   end
> >
> >   class PersonTest < Test::Unit::TestCase
> >     # This overrides the method in the superclass
> >     def setup
> >     end
> >
> >     # This overrides the method in the superclass
> >     def teardown
> >     end
> >
> >     # Only the setup and teardown methods in this class will be called
> >     def test_name
> >     end
> >   end
> >
> > Becomes ...
> >
> >   class Test::Unit::TestCase
> >     setup do
> >     end
> >
> >     teardown do
> >     end
> >   end
> >
> >   class PersonTest < Test::Unit::TestCase
> >     setup do
> >     end
> >
> >     teardown do
> >     end
> >
> >     def test_name
> >     end
> >   end
> >
> > It plays nicely with fixtures and should be completely backwards
> > compatible with existing code that uses setup and teardown methods.
> >
> > Install with script/plugin install
> >
http://svn.viney.net.nz/things/rails/plugins/testcase_setup_and_teardown_with_blocks
> >
> > If anyone can come up with a better name for the plugin please do
suggest it!
> >
> > -Jonathan.
> > _______________________________________________
> > Rails mailing list
> > Rails@lists.rubyonrails.org
> > http://lists.rubyonrails.org/mailman/listinfo/rails
> >
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

On 6/11/06, Jonathan Viney <jonathan.viney@gmail.com>
wrote:
> SImple :). I wanted to define setup/teardown code in test_helper.rb as
> well as the test files themselves. I also have another plugin that
> will want to add bits of setup/teardown code and this makes it very
> easy.
>
> In my opinion this is actually a weekness in Test::Unit. Rails already
> hacks around it to make fixtures work by aliasing setup/teardown
> methods when you define your own method. This just takes it one step
> further.
>
Have you tested rSpec instead and seen if you are happier?
I started using it a week ago. Felt more natural than the Test framework.

-- 
--------------
Jon Gretar Borgthorsson
http://www.jongretar.net/

Thanks for that, I hadn''t seen rSpec. It looks very interesting.

-Jonathan.

On 6/12/06, Jon Gretar Borgthorsson <jon.borgthorsson@gmail.com>
wrote:
> On 6/11/06, Jonathan Viney <jonathan.viney@gmail.com> wrote:
> > SImple :). I wanted to define setup/teardown code in test_helper.rb as
> > well as the test files themselves. I also have another plugin that
> > will want to add bits of setup/teardown code and this makes it very
> > easy.
> >
> > In my opinion this is actually a weekness in Test::Unit. Rails already
> > hacks around it to make fixtures work by aliasing setup/teardown
> > methods when you define your own method. This just takes it one step
> > further.
> >
>
> Have you tested rSpec instead and seen if you are happier?
> I started using it a week ago. Felt more natural than the Test framework.
>
> --
> --------------
> Jon Gretar Borgthorsson
> http://www.jongretar.net/
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

A good introduction video.
http://video.google.com/videoplay?docid=8135690990081075324

On 6/11/06, Jonathan Viney <jonathan.viney@gmail.com>
wrote:
> Thanks for that, I hadn''t seen rSpec. It looks very interesting.
>
> -Jonathan.
>
> On 6/12/06, Jon Gretar Borgthorsson <jon.borgthorsson@gmail.com>
wrote:
> > On 6/11/06, Jonathan Viney <jonathan.viney@gmail.com> wrote:
> > > SImple :). I wanted to define setup/teardown code in
test_helper.rb as
> > > well as the test files themselves. I also have another plugin
that
> > > will want to add bits of setup/teardown code and this makes it
very
> > > easy.
> > >
> > > In my opinion this is actually a weekness in Test::Unit. Rails
already
> > > hacks around it to make fixtures work by aliasing setup/teardown
> > > methods when you define your own method. This just takes it one
step
> > > further.
> > >
> >
> > Have you tested rSpec instead and seen if you are happier?
> > I started using it a week ago. Felt more natural than the Test
framework.
> >
> > --
> > --------------
> > Jon Gretar Borgthorsson
> > http://www.jongretar.net/
> > _______________________________________________
> > Rails mailing list
> > Rails@lists.rubyonrails.org
> > http://lists.rubyonrails.org/mailman/listinfo/rails
> >
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

-- 
--------------
Jon Gretar Borgthorsson
http://www.jongretar.net/

I''ll try to fork the thread instead of hijacking it :)

With rSpec, is there anything analogous to autotest? I like the
positive-assert way BDD poses tests but the two things that are (to me)
stumbling blocks are:

- no autotest that I know of :(
- no clear migration path for existing projects

rSpec seems faster that Unit::Test. Could that be true?

Thanks
--
View this message in context:
http://www.nabble.com/-ANN--testcase_setup_and_teardown_with_blocks-%28aka-%22The-plugin-with-the-very-long-name%22%29-t1768634.html#a4823271
Sent from the RubyOnRails Users forum at Nabble.com.

On Jun 12, 2006, at 12:31 AM, s.ross wrote:
>
> With rSpec, is there anything analogous to autotest? I like the
> positive-assert way BDD poses tests but the two things that are (to  
> me)
> stumbling blocks are:
>
> - no autotest that I know of :(
> - no clear migration path for existing projects
Regarding migration from Test::Unit, see test2spec [http:// 
rspec.rubyforge.org/tools/test2spec.html]. I haven''t used it; I just  
know it''s there.

Craig