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.
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.. ;)
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 :)
Things like aspect orientation and separating of concerns are really trivial for me. I mean I develop software and I write an aspect when I see there is a need for that. I use it pragmatically, and the number of my custom aspects is increasing every few days last weeks.
But as we see not for all people that’s the case. I will try to tell how it looks from my position. And I must start from the beginning: the client of application.
To familiarize with a business domain is the first and most important thing.
It is your client who drives the application, so the first thing is to dive into the client’s business and to look what’s there. But, just don’t spend too much time there. Practical way (agile?) says: it would be nice for you client to see the first version of application very soon. So I implement the domain – simple Java classes and methods and plain JUnit tests.
And in the first week of development I’m only worried about implementing first business task of my client. I don’t think about persistence (you use Prevayler for prototyping, don’t you?) or any other system “services” – it is not important right now. Client is important, and time is important.
And it happened, when I worked this way, I’ve started to see things differently. Some years ago I tried to design a whole system at once. It is impractical. Requirements will change, client will wait. It just doesn’t work.
So I try to think only about functionality of the core system and nothing more. The rest of the system are system’s services – non functional requirements like authorization or tracing support – they will come at a later stage, when need arises. Then I will take care of those services – by implementing an aspect of course.
Like Andrzej Krzywda assumes: one can practically add any orthogonal functionality to an application at any given moment of time. And that is true. It worked out for me with authorization and the rest of my aspects.
Persistence strategy as I believe was the strongest point in my developer’s history. When you choose simple persistence, then you don’t have problems others do. This is the right direction: to get rid of problems. And “simple” doesn’t mean primitive. It is the art to make complex things look simple. I found when code looks clean, many things become brighter. And it is persistence that makes your code look uglier at most of the time. But I don’t want to talk about this topic right now – have a look on PAT, and you’ll see my way..
Need the examples of the code I create? PAT provides a Forum demo ready to extends to you super-duper, enterprise solution…