[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Generic way to test for expected SystemCallError

Daniel Berger

11/22/2006 4:32:00 PM

Hi all,

Ruby 1.8.x

I've got a few tests where I'm looking for expected errors. These are
various system call errors. The problem is that the exact Errno is
different from platform to platform, so I end up writing stuff like
this:

assert_raises(Errno::EACCES, Errno::ENOTEMPTY){ Dir.unlink('some_dir')
}

This isn't very robust, since a new platform might fail with a
different kind of Errno. What I would like is a way to have this test
succeed:

assert_raises(SystemCallError){ Dir.unlink('some_dir') }

The problem is that assert_raises looks for a specific error class. Is
there a way to tell TestUnit to expect any error that's a subclass of
SystemCallError?

Thanks,

Dan

PS - I see from the documentation that assert_raise is deprecated in
1.9. What's replacing it?

3 Answers

Stefano Crocco

11/24/2006 9:34:00 PM

0

Daniel Berger wrote:
> Hi all,
>
> Ruby 1.8.x
>
> I've got a few tests where I'm looking for expected errors. These are
> various system call errors. The problem is that the exact Errno is
> different from platform to platform, so I end up writing stuff like
> this:
>
> assert_raises(Errno::EACCES, Errno::ENOTEMPTY){ Dir.unlink('some_dir')
> }
>
> This isn't very robust, since a new platform might fail with a
> different kind of Errno. What I would like is a way to have this test
> succeed:
>
> assert_raises(SystemCallError){ Dir.unlink('some_dir') }
>
> The problem is that assert_raises looks for a specific error class. Is
> there a way to tell TestUnit to expect any error that's a subclass of
> SystemCallError?
>
> Thanks,
>
> Dan
>
> PS - I see from the documentation that assert_raise is deprecated in
> 1.9. What's replacing it?

The simplest way to do this which comes to my mind is to use the fact that the
exceptions you need are the only constants in the Errno module. This allows
you to write

assert_raise(*(Errno.constants.map{|c| Errno.const_get(c)}))
{Dir.unlink('some_dir')}

Errno.constants gives you an array with the names of the constants, which are
the names of the exception claesses you're interested in. The map method
transforms the array of names in an array of classes, obtained using
Errno.const_get

As for assert_raises being deprecated, I think it's simply a matter of names,
since the method replacing it is simply assert_raise (without the final s).

I hope this helps

Stefano

Daniel Berger

11/25/2006 12:25:00 AM

0


Stefano Crocco wrote:
> Daniel Berger wrote:
> > Hi all,
> >
> > Ruby 1.8.x
> >
> > I've got a few tests where I'm looking for expected errors. These are
> > various system call errors. The problem is that the exact Errno is
> > different from platform to platform, so I end up writing stuff like
> > this:
> >
> > assert_raises(Errno::EACCES, Errno::ENOTEMPTY){ Dir.unlink('some_dir')
> > }
> >
> > This isn't very robust, since a new platform might fail with a
> > different kind of Errno. What I would like is a way to have this test
> > succeed:
> >
> > assert_raises(SystemCallError){ Dir.unlink('some_dir') }
> >
> > The problem is that assert_raises looks for a specific error class. Is
> > there a way to tell TestUnit to expect any error that's a subclass of
> > SystemCallError?
> >
> > Thanks,
> >
> > Dan
> >
> > PS - I see from the documentation that assert_raise is deprecated in
> > 1.9. What's replacing it?
>
> The simplest way to do this which comes to my mind is to use the fact that the
> exceptions you need are the only constants in the Errno module. This allows
> you to write
>
> assert_raise(*(Errno.constants.map{|c| Errno.const_get(c)}))
> {Dir.unlink('some_dir')}
>
> Errno.constants gives you an array with the names of the constants, which are
> the names of the exception claesses you're interested in. The map method
> transforms the array of names in an array of classes, obtained using
> Errno.const_get

Ugly, but I guess it will have to do. I'll probably wrap that in its
own method. Perhaps I can convince Nathaniel to either add a
"assert_raise_kind_of" method, or allow assert_raise to take another
argument.

> As for assert_raises being deprecated, I think it's simply a matter of names,
> since the method replacing it is simply assert_raise (without the final s).

Oh, I could have sworn they were both deprecated. Perhaps I was
looking at old docs. Disregard. I can't wait to go through all of my
tests and update those. Not.

Thanks,

Dan

Edwin Fine

11/25/2006 6:10:00 AM

0

I had the same issue with TestUnit. I wound up writing my own
assert_raise function, which I named assert_raise_s, based on the
TestUnit assert_raise code. I then extend test/unit with the code.

require 'test/unit'
require 'assert_raise_s.rb'

I tried to attach the code but am getting a Rails Application Error.
Should I post the code itself?

--
Posted via http://www.ruby-....