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:[email protected]>
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 <[email protected]
<mailto:[email protected]>>:
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
<[email protected] <mailto:[email protected]>> 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
<[email protected] <mailto:[email protected]>> 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
[email protected] <mailto:[email protected]>
https://dev.eclipse.org/mailman/listinfo/aspectj-users
_______________________________________________
aspectj-users mailing list
[email protected] <mailto:[email protected]>
https://dev.eclipse.org/mailman/listinfo/aspectj-users
_______________________________________________
aspectj-users mailing list
[email protected] <mailto:[email protected]>
https://dev.eclipse.org/mailman/listinfo/aspectj-users
_______________________________________________
aspectj-users mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/aspectj-users
--
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
[email protected]
https://dev.eclipse.org/mailman/listinfo/aspectj-users