Re: [aspectj-users] Using the -injar compiler option

[Wes Isberg <wes@xxxxxxxxxxxxxx>]

> Suppose I have a method on a class that needs to do something
> if a file doesn't exist.

One way to test that particular case is to refer to java.io.File, 
but use an aspect to make it appear that the file does not exist:

  boolean around() : 
         cflow(execution(void MyFileTest.testNotExists())
         && call(boolean File.exists()) {
      return false;
  }

(You can of course be more specific about when you return false.)

More generally, sometimes you can control enough at a particular
join point -- returning different values, altering input, 
re-running the ensuing control flow, throwing exceptions --
that you don't need a mock object.  If you need more than you
can do at a join point, you might get by with keeping state 
in the a cflow aspect associated with the test case.  If that
doesn't work, you might have to use a mock object.  I prefer to
start with advice and aspects as less intrusive and move to 
mocks only if I have to (or if I'm repeatedly targetting an 
interface and I only need to proxy a couple methods -- i.e.,
if I can reuse the mock in multiple test cases).

When an aspect implements part of the test flow or setup,
consider putting it near your test case so it's easy to 
understand what's going on even without IDE support:

  public class FileSystemTests extends TestCase {

      public void testNotExists() {
        ...
      }
      static aspect FileTestController {
          boolean around() : 
             cflow(execution(void MyFileTest.testNotExists())
            ...
      }
  }

or 

  public aspect FileSystemTests extends TestCase {

      public void testNotExists() {
        ...
      }
      boolean around() : 
          cflow(execution(void MyFileTest.testNotExists())
          ...
  }

For more on these kinds of techniques, see Software Development's
~test inoculated~ article:

    http://sdmagazine.com/articles/2002/0205/

Wes

P.S. - 

> What I'm thinking is that I would
> like to have some 'woven' system jars that could be used during
> development/testing and and runtime the regular jars would be used

I'd be careful about not testing with the actual runtime 
classes unless I were pretty sure my changes did not affect things.

James Howe wrote:
> 
> I'll write up a bug report.  As to weaving rt.jar, I would love to come up
> with an alternative solution, but right now it's the only easy solution
> I've come up with.  Here's an example of the sort of thing I'm trying to
> work with.  Suppose I have a method on a class that needs to do something
> if a file doesn't exist.  The code would be written to use the Java file
> class.  It might instantiate an instance of file based on a name and then
> ask the File if it exists.  What I want to be able to do is configure my
> test case to use a MockFile instead of the real file.  File doesn't
> implement an interface so I have to go through gymnastics to come up with a
> MockFile.  I would then have to rewrite the method to take a File as a
> parameter (in reality some cooked up File interface) which could then be
> swapped out for a MockFile at test time.  What I'm thinking is that I would
> like to have some 'woven' system jars that could be used during
> development/testing and and runtime the regular jars would be used.
> 
> On Thu, 15 May 2003 13:38:28 -0700, Wes Isberg <wes@xxxxxxxxxxxxxx> wrote:
> 
> >
> > Hmm... looks like a cycle in the InstructionHandle list:
> >
> > ---- Utility.java
> > public static int getSourceLine(InstructionHandle ih) {
> > if (ih == null) return -1;  <snip...>
> > return getSourceLine(ih.getNext()); // StackOverflow here
> > }
> > ----
> >
> > It doesn't seem like this *should* be a side-effect of decompiling
> > classes also in the parent loader, but...
> >
> > In any case, it's definitely worth writing up as a bug.
> >
> > http://dev.eclipse.org/bugs/enter_bug.cgi?product=AspectJ
> >
> > (Weaving rt.jar seems like a lot of work to isolate test cases;
> > is there some other way to do it?  We don't recommend users
> > weave Java classes.)
> >
> > Thanks for bringing this up -
> > Wes
> >
> 
> --
> James Howe
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/aspectj-users