Having said that, I am failing to see a contradiction between my
suggestion and yours, dear Félix.
There is none... I was just exposing my thoughts and the alternatives.
:) Sorry if my comment was confusing.
The only technical point is: if you use only Mockito, you can't weave
only one aspect at the time. And you can't simply decide when to weave
it into which class to write a pure unit test of the aspect like you can
do with a class.
--
Alexander Kriegisch
Am 06.02.2014 um 19:43 schrieb Félix-Antoine Bourbonnais
<fbourbonn...@rubico.info <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto:aspectj-users@eclipse.org>
https://dev.eclipse.org/mailman/listinfo/aspectj-users
_______________________________________________
aspectj-users mailing list
aspectj-users@eclipse.org <mailto:aspectj-users@eclipse.org>
https://dev.eclipse.org/mailman/listinfo/aspectj-users
_______________________________________________
aspectj-users mailing list
aspectj-users@eclipse.org <mailto: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 <mailto: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 <mailto: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
<http://linkedin.com/in/fbourbonnais/fr>
_______________________________________________
aspectj-users mailing list
aspectj-users@eclipse.org
https://dev.eclipse.org/mailman/listinfo/aspectj-users
