Testing those aspect creatures

On testing aspect oriented systems

I was always wondering what is this hype about testing aspects or aspect oriented systems about? Or maybe there isn’t any..
Here you’ll find concrete examples of my JUnit tests of my Ilybra application and PAT framework.Test type no. 1: test of PAT¬†aspect itselfWhen applying PAT to any software I have to test if PAT works correctly. To do that I need to write tests of the aspect. And PAT is a persistence aspect, so what I need to test is if the data is really stored on the disk after some persistent operation. And it means I must check if the database I use (Prevayler) behaves correctly: stores data changes on the file system, when recovering does it read files in correct order and does it restore the data after failure.
And persistent operation is PAT’s transaction invoked on business object (BO).So here is sample code, of how do I test my PAT aspect:

Test type no. 2 – testing Ilybra‘s business methods

It is trivial to test Ilybra application and its business methods. Due to the fact, any business class created with PAT is plain Java class without any dependency on external resources, I can just invoke the object’s methods without any “mocks fun”.
Below you’ll find one of my JUnit tests for testing user story: “Lend book to a reader”. The expected behaviour after invoking method lendBook is the copy must be located within reader’s current list of lend copies and the copy itself has to have a reference to the reader.

Code of the test case – again – without any cheating it is one of my original test cases. There is no external configuration to the test case. None of aspects is applied here, no custom advice here except PAT‘s annotations on transaction methods (lendCopy).

Note: I test core functionality here. And this is the most unique. PAT lets you create such simple test cases for an application

With those two examples above I think I’ve just exhausted my “AOP & testing” topic.

Have fun and take care!