I was watching this infoQ presentation by Alexandru Popescu and Cedric Beust on testing when I realized that a big market for testing is seriously neglected.

Regarding my use of testing I would say that JUnit pretty much fills my bill and I don’t see a need to move to TestNG. I was watching the presentation not so much as to know more about TestNG, but to get some exposure to the market for testing products (*). So the features which were presented and which were said to be in a high demand from the users were the ability to define test groups, to test data connectivity and to define dependencies between tests (**). Pretty fair, I would take this functionality to be a logical progression from the ability to run a bunch of tests at random as JUnit lets you do it, you are basically starting to look at the tests you run from a higher level and you start looking for ways to aggregate these tests into higher-level constructs, such as test groups, which can then be manipulated according to various needs.
So far I would say that Test NG is looking at ways to manage the complexity coming out of a high number of tests. Test NG is for test-heavy shops, where testing is considered a concern on par or close to development. Not a bad thing and I pretty sure that TestNG covers some functionality which is in high demand by Java developers.

There is, however, one need for testing that so far it is largely unsatisfied and sorely missed: the need to test workflows or series of events. Let’s say that you have an application that is a series of MDBs, each accepting messages, transforming them and then outputting them to the next MDBs. You would want to be able to test this application end-to-end.
Let’s say that you have an application that receives market trades, needs to process them and then transform them in order to send them downstream to tax systems, settlement systems, etc… You would want to put thru a trade, set-up in a certain way and then trace its execution thru these flows and determine if, in what stage and in what shape has this trade reached the Application-to-Tax-System gateway.
When I think about work-flow testing I usually think about defining a message, inputting this message into a work-flow engine and then defining interceptors to see how the original message has been manipulated at various stages. You may need to test both the work-flow itself (to see if the message has been going thru the work-flow that it needed to go thru), the end-result (to see where the message has been forwarded to and in what shape) as well as how it behaves at various stages in this workflow (if needed). I see work-flow testing primarily concerned with interception of messages (and this would probably be a great use of AOP) and with the possibility to correlate messages passing thru this work-flow with the original message.

OS testing tools so far are limited to synchronous testing. I wonder at what point will the need for work-flow testing become so pressing and the demand for it so great so that one OS shop will start doing something about implementing a testing framework for testing workflows. Then we could use Event-Driven-Testing for testing an application written in a Event-Driven-Architecture manner…

* I know that trying to form an opinion on a market such as the market for OS testing tools from a vendor presentation is a pretty risky business, what you get from vendor presentations is usually distorted because of bias and time constraints but I will assume that this presentation gave a fair image of what users want from testing tools.

** From what I know TestNG is a lot more than some annotations that give you the possibility to form test-groups and test dependencies. However, I would say that these issues are probably considered more important and more aligned with the market for OS testing tools since they were the ones which were included in this presentation.

P.S. If I were to choose one enterprise concern which is not addressed by the Spring stack I would choose work-flow. Spring has modules for integration, batch, transaction management, security management, connectivity to various end-points, etc…, it is missing this capability. From what I see work-flows are used pretty heavily in the enterprise space and for now I think they are mostly implemented either by in-house solutions or by commercial solutions. OS could probably make a contribution in this space as well. And if it does it should probably try to give the developer the ability to test work-flows, or at least make it easy for him/her.

P.P.S. The comments by Alan Keefer on this thread reinforce my beliefs that we need to carry out tests at every level, from high-level to unit test. For a work-flow based system this would mean that we need to test the work-flows themselves and not only the units making them up.

Later edit:  There are actually a few OS workflow tools. OSWorkflow, the ones at the bottom of this article and probably a few others. I should try them at one point.

I was reading this post on infoq about applying AOP for implementing business logic transparently. It was a pretty good example (actually the author displayed a very interesting way of consolidating a series of different business concerns into a general advice using a Map of Command objects), but what caught my attention was a comment at the end of the post:
It always surprises me to see how much code people actually place within the AOP advice creating an architectural dependency on AOP that makes it impossible to reuse in another context such as an explicit programmatic interface. I personally prefer to use AOP (or interceptors) as bridges or adaptors from one domain/layer/tier to another domain/layer/tier. I normally start with creating the underlying system divorced of AOP concerns and then add AOP into the mix to alleviate the coding effort and simplifying the programming model for typical extension use cases. I always ensure that it is possible to use an particular feature without the presence of a particular framework or instrumentation runtime.

The reader had a pretty good point: you can use decorators* for implementing this business logic. So when would you use AOP? I would use for implementing business logic concerns if they are cross-cutting concerns, if they apply widely across the code-base. In the above example the advice was a notification module that was sending an email when the user was registering. If you would have needed to send a notification when the user was purchasing an item, when an item was shipped to the user, etc… you would have a cross-cutting concern (a business logic concern) that needs to be applied transparently to the application. Another example when I would use AOP is for transient concerns, for concerns that should not modify the code base but that need to be implemented.
Business logic advices come with management costs (you have a piece of business logic detached from your code-base, you have to manage that). Implementing interceptors thru decorators come with coding costs (you usually need to create a new class). One should look at these costs and determine which approach is more cost-effective. As always, use AOP only for binding components together, the business logic advice should contain no business logic at all, but simply logic for binding a business logic bean (the notification module in the above example) to a different bean. I am not sure if the example followed this approach, though.

* AOP can be thought of as decoratoring unleashed, an advice applied to a class is a decorator.

I think it is obvious, but I have not seen it mentioned anywhere: you need to test an application which has been AOP-ed (which has been built using AOP). Suppose that you wrote an advice that re-prices a shopping cart. You should unit-test the advice on its own, unit-test the application on its own, but you should also unit-test the advice applied to the application (just to make sure that the advice has been applied properly and is well integrated into the application). The application which has been enhanced by aspects is a brand new thing (well, maybe not) which needs to be unit-tested as well (especially if the advice is modifying its state as the shopping cart re-pricing advice does).

I wonder if you could/should compose unit-tests (let’s say JUnit tests) similar to the way you compose applications. The new unit-test (the one that tests the application as it has been modified by the advice) could probably be derived from the 2 unit-tests, it would be interesting to see if you could compose the new unit-test with the same ease with which you compose the application. One problem with unit-testing an AOP-enhanced application that I see is the difference between the ease of use with which an advice can be applied to a code-base and the ease of use with which you can create a unit-test which can test the new application. Very likely the advice is applied in configuration while the AOP test is written in code, there is a pretty big difference in the time spent on creating the new application vs the time spent on creating the tests for the new application. I wonder if testing platforms should not be tweaked in order to allow for unit test re-composition.

It would be interesting to know why nobody is talking about this. Could it be because AOP is being used mainly for infrastructure issues which do no inject significant behavior into the application (I see unit-testing AOP-enhanced applications being very important for weaving business-logic advices into an application)? Could it be because of the difference in the costs of creating an AOP-enhanced application and testing it? Once again, time will tell…

P.S. This post is pretty much a collection of various thoughts that I have about AOP and unit testing. I realize that it is not very well structured, but I didn’t have the time to dwell too much on it.

A while ago I made the case for business logic aspects, arguing that in a sense AOP is similar to SOA: you basically compose together an application by weaving business logic aspects where necessary. The example I gave was that of a taxing aspect that gets applied transparently to various financial operations so that when carrying out a financial operation you also tax it.
Pretty good in theory, and I still maintain the same opinion: if you can apply business logic concerns transparently thru AOP you should probably do it.
However, when watching this interview and this interview I realized that one big piece is missing from this picture: domain aspects modeling. The person in the first interview advocates using annotations for modeling aspects, approach that I don’t think scales pretty well. Aspect modeling is very crude for the time being (it is true that we are at the beginning of the adoption period for AOP so a lot of things are not in place) and this would imply that you cannot model complex aspects and complex interactions between aspects and advised classes. Pretty much all the business logic aspects I came across in different interviews are very crude and consist of very small operations, engaging the advised class in a very limited ways.
I guess this is only how far you can go ahead today. Tomorrow will probably be different, the case for business logic aspects grows and at one point the emerging complexity will have to be managed one way or another.

P.S. From what I read I see that annotations are widely used for creating pointcuts. This approach means that basically you are creating your pointcuts in Java code and not outside of it (in an AspectJ query or Spring config files) which is, to a certain degree, contrarian. I wonder if this is not related to the fact that currently you can manage your Java codebase a lot better than your spring.xml files or your AspectJ queries.

A while ago I wrote a post regarding the difference between SOA and CORBA. I saw this assertion on a few bulletin boards a few times and I felt I needed to write about it. Well, if SOA is different from CORBA then what would it be similar to?
Let’s say that you have an enterprise-wide service. Let’s say that a financial institution needs to apply taxes to every financial operation it makes. The enterprise-wide service would be the tax program and the actors would be the software programs that trade currencies, stocks, bonds, accrue interest, etc… Every trade that gets made has to get taxed so your tax service has to interact with all pretty much all the software in the enterprise.
Now suppose that you have this gigantic application that a financial institution uses for making stock trades, buying bonds, applying interest to accounts, etc… Obviously all the financial operations must be taxed. The easiest way to implement tax across all the financial operations would be thru AOP. You would define a tax cross-cutting concern and bind it to the appropriate methods.
The cross-cutting concern would exhibit the same relationship to the application as the SOA service exhibits to the enterprise: they are identical pieces of functionality that apply to very different actors. The cross-cutting concern applies to various methods in an applications, the SOA service applies to various silos in an enterprise information system. From a functional point of view a cross-cutting concern is very much like a service. There is a huge difference in scope between the two concepts, but at the bottom of it they are very similar.

One more thing. SOA is considered the domain of business analysts, the business analyst driving most of the interactions between different services and applications in an enterprise information system. Given the similarities between SOA and AOP it would seem that AOP would be best effective when the interactions between aspects (or services as they are known in SOA) and methods (or applications as they are known in SOA) are managed by business analysts rather than developers…
Good food for thought…

Later edit: I understand that currently the advices used mostly in AOP are concerned with infrastructure issues (concurrency, security, transactions, etc…). However, AOP leaves the door open to assembling applications so that you can bind a piece of functionality to another piece of functionality like the above example with taxes. In this case the usual pointcut semantics will probably not suffice (unless you use annotations) because the advices will not be applied to objects which are related by infrastructure issues (such as persistence or concurrency) and are grouped together by namespaces (such as package names), but rather to objects which are related by business-logic issues (such as manipulating funds). This grouping is probably harder to translate into pointcuts.
Anyway, I think the interesting development in AOP lies with applying advices because of business-logic affinity rather than because of infrastructure needs. You have one great example here.

I am looking at AOP as an example of applying the theory of Division of Labor to development. With AOP it is possible to have different types of professionals working on the same project at the same time.
In theory a security expert would secure the application or even better a security expert in one domain would secure one part of the application, while a security expert in another domain would secure another part of the application, a transaction expert would trace transaction boundaries within the application, a concurrency engineer would serialize calls to a state repository in order to implement concurrent access, etc… I say this is possible in theory because managing this interaction takes some good managerial skills and processes, processes with which I am not familiar for the time being.
The division of labor is a process that scales very well in diversity and ultimately in complexity. Various tasks are assigned to people trained specifically for them and are executed in an efficient manner. At the end of it the process has managed to put together a product which is quite complex and has received input for people of various backgrounds. This could be very well the solution to managing complex interactions when developing software: dividing them into tasks which can be performed individually by experts and assembling them at the end. Just like when you have a coffee you don’t have to worry about growing a coffee tree, harvesting the beans and roasting them because someone else did that for you when you are writing an application you should not concern yourself with securing it or implemeting failover thru exception handling because someone else would do this as well.
The division of labor pulled the human race out of the Middle Ages and into the industrial age. Hopefully AOP will be able to pull large, complex projects out of the quagmire of pointless meetings, weekly merges, versions, etc… and into functional, deployed applications.

P.S. I wrote this post on the most horrible coffee I had in a long time. If it had an effect on the post itself I am sorry.
P.P.S. Separation of concerns resembles the division of labor as well.

One big difference between Spring’s proxy-based AOP implementation (referenced from now on as Spring AOP) and annotation-based AOP is the fact the Spring AOP declares the advices outside of the code while annotations declare the advice in the code. This causes some side effects:

1) Spring AOP lets you apply different behavior to the same class in different instances (actually you can do this in the same instance). It would be possible to download an open-source JEE application (such as a B2C shopping cart) and customize it without changing code resulting in different instances of the same app. For example, you would be able to declare that various steps in the checkout are transactional, apply different security requirements from instance to instance without changing the downloaded code.

2) The fact that annotation-based AOP binds behavior to code implies some development coupling: you have to develop or at least design the advice before you develop the class being advised. Ideally you would develop the advice independent of the code it gets applied to.

3) Annotation-based AOP creates horizontal relationships between classes that are very hard to change. All the classes sharing the same advice are tied together. Suppose that you have a Transaction annotation applied to you account manager, user signup manager and checkout manager. It would be very hard (and would require quite a lot of code-juggling) to change the app so that only your checkout process is transactional. These horizontal relationships (which as far as I know have not been integrated into modeling tools) should probably not exist at the code level, but at the application-deployment level. Cross-functional behavior should probably be applied at deployment time when the user’s requirements are ready to be implemented.

4) Annotations may degrade portability. One example would be the core EJB3 annotations for persistence. These annotations are platform independent since they are part of the EJB3 spec, however, these annotations are probably insufficient for real-life deployment because they do not allow for application tuning (such as data caching for example). In order to add caching to an EJB we would probably have to add server-specific annotations, and these server-specific annotations ruin the portability between application servers. With Spring AOP we could write an aspect that would piggy-back on the server-specific cache and advise the DAO with this aspect at deployment time. We could change the cache pretty easily by creating a new aspect for a different cache and advise the DAO with this aspect at deployment time.

5) Spring AOP creates a new role in the product’s life-cycle: the application assembler role. This role (probably best fulfilled by a business analyst which has a relation with the customer) would allow for making the application more flexible to customer’s requirements. A business analyst should be able to look at an application, determine what type of behavior should be attached to, or detached from its various parts and attach or detach that behavior. Supposing that this behavior doesn’t exist the business analyst should be able to have it developed in an advice that is independent of the overall application and advise various parts of the application with this advise.

I think that Spring’s proxy-based AOP is a better proposition that AOP thru annotations. Annotations promote relationships that are hard-coded and unless are specified by the domain problem they should be better implemented outside of code.