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 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. 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 list
>> aspectj-users@eclipse.org
>> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>
> --
> Félix-Antoine Bourbonnais
>
> Twitter : @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
