On 10/26/05, Trans <transfire / gmail.com> wrote:
>
> > Is this acceptable in the RCR design?
>
> Ed, you're right on the money, Right On The Money.
>
> > Was it already implied?
>
> I believe we make a passing mention of AOP in general having applicable
> to testing. But we offer no details in how cuts may be used for this.
> Now you've lighted the way --and an interesing way at that. Very cool.
>
> Thanks for sharing this.
>
> T.

No problem, just something I've been thinking about. Brian Button (and
others,) have said in testing, don't test the disk, and don't test the
I/O subsystem, don't test the OS, and don't test the built-in std
library. So, if the application is supposed to do these things, then
they are hard to test. Which has given rise to many diverse ways of
addressing this via mocking, using interfaces, dependancy injection
and so forth.

Ruby is nice, because you can mess about with its innards, and thus
get around some of these difficulties. Although, with TDDing and
refactoring, you shouldn't paint yourself into corners in the first
place. But for legacy code, this approach has some merit, IMO.

AOP strategies for unit testing are nothing new:
http://blogs.codehaus.org/people/vmassol/archives/000138_aop_unit_testing_example.html

Another potential use of AOP with testing is in fault injection:

cut IMHacker < Kernel
   def exec(command, *args)
       raise SecurityError "Caught ya, you lazy good-fer-nuthing low-life"
       ...
   end
end

def test_catchem
     assert_raise(SecurityError) { exec("cat /etc/passwd") }
end

... where the exec call would really be buried in another class somewhere.

Any is there any prototypes of this available anywhere, or is it too
soon to ask that yet?
I'd vote for this, but RCRchive won't let me in.

Ed