It’s a well specified app with known functional requirements. It’s quite real world scenario app. Its implementation can be compared to other platforms. So it’s a good showcase for what I’m going to present.
Will Include (not limited to)..
- domain usecases
- coffeescript mixins
- rails ActiveRecord .. not
- … ? who knows..
On testing aspect oriented systems
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!
On aspects in Ilybra project…
Great people like Ron Bodkin talk about the pragmatic way of doing software. So why don’t me, when I have this experience and I’m just hot to tell the world to look at the other side of this matrix..
Ilybra is a battlefield when it comes to aspects. Ther first aspect was tracing of course, the rest you see below, and today I got an idea on another one to my collection. Some people will even call my aspects “enterprise”! As you wish :) I don’t know the meaning of that word. I just develop an application for my library ladies.. ;)
Like it was said in the Ilybra: introduction, Ilybra utilizes some custom made aspects. They are:
- authorization and authentification
- optimization of access to some sorted data collection
- tracing execution of Struts actions
- dirty problem with null parameters
- reseting Struts’ forms
- measure the action invocation time
- …and will be more, when need arises
- Oh my, and I’ve just forgotten about the most important one: persistence – see how invisible it is my way :)
Many! lines of code has just disappeared from my classes. This is the core value of aspects. My code is cleaner.I will demonstrate you my Struts’ action code with: tracing, authorization, persistence, returning empty String instead of null, resetting forms and measuring time of invocation of action – ufff, a lot :) :
My full, original code (without any cheating or removal lines of code for the sake of the presentation of the example) of user story: Prolong copy on reader’s account: enter new date, accept choice, view confirmation.
Note: of course, there exists one, additional, global ilybra-aop.xml AOP configuration file for defining pointcuts.
Interested in library.prolongCopy(..) or library.getCopyById(..)??
..Authorization and authentification are common in applications. And so it is with Ilybra. It is 2 years now, I started to work on the application, but only from the last week the system must authorize a reader to access his account.
What is important here I’ve managed to add this concern – orthogonal concern – after the application was finished. I’ve done it with one simple aspect listening on all Struts actions, which checks if there is a User object in a session. Implementation is trivial. And aspect oriented way turned out to work. (This implementation could also be done using “servlet’s filters”, as they also crosscut expected behaviour in this particular example).
Code of the aspect on the plate:
I hope those examplets will clear your mind for a moment :)