What we've done in testing that has worked well for us is have surefire set up to use the aspectj agent in the runs and then used spock to tests the side effects of the aspects being woven.
There's a really simple project I have on github that screws with the platform MBean server and makes it return fake instances of various mbeans. In practice, this project on github is not really good for anything, but it does show off one way of testing aspects using spock - for the spock tests I have simple tests like: https://github.com/ryangardner/jmx-aop-fun/blob/master/src/test/groovy/drips/MXBeanSwaparooSpec.groovy In other places we've used AOP to do more complicated things, we will similarly test the side effects of the aspects being applied. For instance, in one place where we are using aspects a lot for monitoring, our unit tests have some simple constructs to test that after hitting the aspects that the stats are increased in our stats registry as we would expect them to be: def "test weaving of java.sql.CallableStatement.executeUpdate(String,int[])"() { setup: CallableStatement statement = Mock() when: statement.executeUpdate('UPDATE TABLE', [0] as int[]) then: def newSize = old(MetricsRegistry.getInstance().getMetrics().size()) + 1 MetricsRegistry.getInstance().getMetrics().size() == newSize } Using spock has helped us a lot because the aspectj weaver will, in most cases, let us use simple spock mocks and have them woven (in the above case the mock for the CallableStatement is woven by the aspectj agent so that the call to "executeUpdate" has our aspects woven around it). In other places, we will test various pieces of the aspects themselves by mocking up joinpoints and passing them in and making sure that the aspects themselves behave as we want them to behave. Using spock for testing aspectj has, for us, been very intuitive because run our setup, put a simple statement in our "when" block that matches something we intend to weave, and then in our "then" block make sure that any side-effects of our aspect happened. Ryan On Thu, Feb 6, 2014 at 5:20 PM, Félix-Antoine Bourbonnais < fbourbonn...@rubico.info> wrote: > > OTOH, it is also important to check if a class still shows the desired > behaviour if woven by multiple aspects. But that is more of an integration > test again. > > > Of course. > > > I guess the original poster should have a set of ideas now. Thanks for the > discussion. > > > :) > > Thanks, > > _______________________________________________ > aspectj-users mailing list > aspectj-users@eclipse.org > https://dev.eclipse.org/mailman/listinfo/aspectj-users > Alexander Kriegisch <alexan...@kriegisch.name> > 6 février 2014 15:08 > I was explicitly mentioning mocking frameworks loke Mockito and Powermock > and also the possibility to add classes to your test suite with the sole > purpose lf being matched by advice to be tested. The latter are effectively > mocks and perfectly suitable to test aspects in isolation, a practice I > strongly support. Unit tests and more integrarive tests are not mutually > exclusive, both of them are needed and - pun intended - just different > aspects of testing. > > Having said that, I am failing to see a contradiction between my > suggestion and yours, dear Félix. > -- > Alexander Kriegisch > > > Am 06.02.2014 um 19:43 schrieb Félix-Antoine Bourbonnais < > fbourbonn...@rubico.info>: > > I agree with you about keeping it as simple as possible. And I also agree > about the fact that you should consider aspects as Java classes. > > 1) On the other hand, the same reason you would want to unit (isolation) > test your classes applies to aspects as well. You can test all classes of > your systems integrated or isolate each one of them with Mocks or do > something in between... Even in the TDD community, you have those schools > (classics or mockists). > > More your call chain is long from a test, more you might be affected by > the Fragile Test Syndrome (because many tests are covering a spot) and > looking for a needle in a haystack when the test fails (why the test > fails). It's a question of balance! > > And the problem with Aspects is a little bit worst because the control > flow is not explicit. So, you might want sometimes to test them in > isolation using mocks instead of relying on an integrated test. > > > 2) If you have multiple Aspects, il could be difficult to be sure which > one is applied when... So you might want to test the matching+behaviour of > each one independently. > > > So, you have some pro/cons arguments and it only depends on you own > context. I strongly recommend you to keep it simple, but also keep your > test as simple and maintainable as possible too. > > Alexander Kriegisch <alexan...@kriegisch.name> > 6 février 2014 13:14 > Well, I like to very much simpler than Félix and you and try not to come > up with a special framework, but use standard build and test tools, namely > Maven and JUnit (or Spock), maybe (Power)mockito if absolutely necessary. > > Question: Why handle AspectJ code differently than Java code? Do you write > tests to check that your Java code actually compiles? No, you run Maven and > if the compile step fails there will be an error. The same is true for > AspectJ if you just use the AspectJ Maven plugin. That plugin also has a > "verbose" switch which produces output for each woven joinpoint. If you > like you can grep on that output and see if one or some of your expected > joinpoints are actually woven. Theoretically you could do this from the > Surefire or later from the Failsafe plugin. As for unit testing, you can > call a woven method and check if it behaves as expected, with or without > mocks. You may even have a dummy class in your test folder with the right > signature to be matched and check how that one behaves, if you do not like > to test production classes. > > As you see, on-board means are enough, you do not need any > AspectJ-specific mocking frameworks, even though Félix's tool sounds nice. > KISS! Keep it really simple. ;-) > -- > Alexander Kriegisch > > > Am 06.02.2014 um 17:59 schrieb Muhammad Adinata <mail.die...@gmail.com>: > > Hello! > > Thanks for very fast response. > > Alexander, > I'm currently trying to generate an aspect based from annotation > information in java source code. The generated aspect is what I wanted to > test. I use it in my personal project for android A/B > Test<https://github.com/dieend/ADIN-Android-Split-Testing-Library>. > The aspect class is really simple in general. What I wanted to test are: > - the aspect compiles correctly > - the pointcut really cut the method > > Lets use this for sample: > Class Hello { > void String hello() { > return "hello"; > } > void String aloha() { > return "aloha"; > } > } > aspect privileged HelloAspect { > around(Hello h): target(h), execution(void Hello.hello()) { > if (SomeOtherClassSingleton.use()) { > proceed(h); > } else { > h.aloha(); > } > } > } > > I want to check the aspect compiles correctly, and the method hello return > "aloha" if SomeOtherClassSingleton.use() returns true. > > > Sean, > That looks really promising! Thank you, I was also searching in SO, but > maybe my query isn't good enough or the question still not popular enough > and beaten by Spring question. > > I have tried your class, but I got this error when running the test (I > modified the class so the info can be accessed when calling compile method): > > directory classpath entry does not exist: C:\Program > Files\Java\jdk1.6.0_38\jre\lib\sunrsasign.jar > directory classpath entry does not exist: C:\Program > Files\Java\jdk1.6.0_38\jre\lib\modules\jdk.boot.jar > zipfile classpath entry does not exist: C:\Program > Files\Java\jdk1.6.0_38\jre\classes > Pipelining compilation > compiling /path/to/aspect.aj > compiling /path/to/Hello.java > Compiler took 507ms > > and then the result return Result.ERROR. Do you have any idea? > > Thanks! > > -- > *Muhammad Adinata* > TOKI 2009 > SMAN Plus Provinsi Riau 9th > 13509022 - Informatika ITB 2009 > > > On Thu, Feb 6, 2014 at 11:07 PM, Sean Patrick Floyd < > seanpfl...@googlemail.com> wrote: > >> I have asked (and answered) a similar question recently: >> http://stackoverflow.com/q/19980876/342852 >> >> Sean Floyd >> >> >> On Thu, Feb 6, 2014 at 4:56 PM, Muhammad Adinata >> <mail.die...@gmail.com>wrote: >> >>> Hello, >>> >>> Is there any way to test standar aspect class (not annotation style) >>> with JUnit or other testing framework? >>> >>> I can't found any guide about it in the documentation, and the >>> annotation style generally tested for Spring. >>> >>> -- >>> *Muhammad Adinata* >>> 13509022 - Informatika ITB 2009 >>> >>> _______________________________________________ >>> aspectj-users mailing list >>> aspectj-users@eclipse.org >>> https://dev.eclipse.org/mailman/listinfo/aspectj-users >>> >>> >> >> _______________________________________________ >> aspectj-users mailing list >> aspectj-users@eclipse.org >> https://dev.eclipse.org/mailman/listinfo/aspectj-users >> >> > _______________________________________________ > aspectj-users mailing list > aspectj-users@eclipse.org > https://dev.eclipse.org/mailman/listinfo/aspectj-users > > _______________________________________________ > aspectj-users mailing > listaspectj-users@eclipse.orghttps://dev.eclipse.org/mailman/listinfo/aspectj-users > > > _______________________________________________ > aspectj-users mailing list > aspectj-users@eclipse.org > https://dev.eclipse.org/mailman/listinfo/aspectj-users > > _______________________________________________ > aspectj-users mailing > listaspectj-users@eclipse.orghttps://dev.eclipse.org/mailman/listinfo/aspectj-users > > Félix-Antoine Bourbonnais <fbourbonn...@rubico.info> > 6 février 2014 13:43 > I agree with you about keeping it as simple as possible. And I also agree > about the fact that you should consider aspects as Java classes. > > 1) On the other hand, the same reason you would want to unit (isolation) > test your classes applies to aspects as well. You can test all classes of > your systems integrated or isolate each one of them with Mocks or do > something in between... Even in the TDD community, you have those schools > (classics or mockists). > > More your call chain is long from a test, more you might be affected by > the Fragile Test Syndrome (because many tests are covering a spot) and > looking for a needle in a haystack when the test fails (why the test > fails). It's a question of balance! > > And the problem with Aspects is a little bit worst because the control > flow is not explicit. So, you might want sometimes to test them in > isolation using mocks instead of relying on an integrated test. > > > 2) If you have multiple Aspects, il could be difficult to be sure which > one is applied when... So you might want to test the matching+behaviour of > each one independently. > > > So, you have some pro/cons arguments and it only depends on you own > context. I strongly recommend you to keep it simple, but also keep your > test as simple and maintainable as possible too. > > > > -- > Félix-Antoine Bourbonnais > > Twitter : @fbourbonnais <http://twitter.com/fbourbonnais> > LinkedIn: linkedin.com/in/fbourbonnais/fr > > > _______________________________________________ > aspectj-users mailing list > aspectj-users@eclipse.org > https://dev.eclipse.org/mailman/listinfo/aspectj-users > >
_______________________________________________ aspectj-users mailing list aspectj-users@eclipse.org https://dev.eclipse.org/mailman/listinfo/aspectj-users
