Pattern Testing is the concept of automatically verifying the good application of architectural/design patterns in code. It uses AOP to perform this feat.

Pattern Testing is a concept I started researching in 2002 on a big project at work. At that time, I was already using Checkstyle and PMD to perform verification of rules. However, I was finding them limited in several ways:

• They were mostly focusing on syntactic rules, whereas I was mostly interested in semantic rule checking. Checkstyle has improved a lot in this area over the past 2 years. However, even though there are some semantic rules , they are usually simple and not very "business"-oriented. Note that this is not to diminish Checkstyle which I find great and use on all projects.
• They were focusing on applying rules on a single file (using AST trees), whereas I was interested in applying rules that span several files (this is necessary for architectural/design checks). As a consequence writing pattern tests using Checkstyle is difficult.
• They were limited to static checks. I wanted to be able to say "ensure that no method call is passed a null parameter", "ensure that there are no more than 10 calls to the database per user case", etc

The result was the Pattern Testing project on SourceForge. It's implemented using AspectJ. It contains some pre-made Pattern Tests but more importantly it lets you write your own. There is Maven plugin that makes it easy to run any Pattern Test on any mavenized project.

The possibilities of Pattern Testing are endless.

Here's an example of a rule that says that we do not want to instantiate business classes (i.e. a class that extends BasicBC). That's because they are instantiated by factories/service managers:

public aspect NoNewOnFrmwkClassesPatternTest
{
     declare error: 
       call(com.some.package.BasicBC+.new(..)) : 
         "Do not instantiate a business class directly";
}      

I used Pattern Tests for some time on that project at work and then I changed job. I was still interested in the concept but with my other open source involvements I didn't take the time to work on it as much as I wanted. Thus it became a bit abandoned. However, these past weeks, I have found renewed interest in the concept for several reasons:

• I was contacted by Matt Smith who was interested in taking the lead of the Pattern Testing project. I gladly handed this over to him and he's now the one driving the project
• I have started working on Cactus2 and as the Cactus 2 architecture is based on AOP, the concepts are very close.
• On the new project I am on, we're starting to want to automate our architectural/design checks and some teams have initiated using Pattern Tests.

Are any of you using Pattern Testing too?

I've given an interview (in French) for the French magazine Courrier-Cadre about the new job of "Offshore Project Manager" that I am currently doing for Pivolis on the BNP Paribas project.

It explains what are the day to day activities of an offshore coach (I prefer the word "coach" to "project manager") on a collaborative development project.

Here are some tasks that we (we are 2 from Pivolis working on this project) are performing on this project:

• Administrative tasks:
• Arrival/Departure administration (Secure id card, Star Team account, Test Director account, Wiki account, JIRA account, mailing lists accounts, etc)
• Organisation of visits (identification of requirement, dates, agendas, people) in both directions Paris -> India and India -> Paris
• Visa handling
• Infrastructure for offshore:
• Infrastructure coordination + improvements (monitor performances, tune tools) - with help from BNPP infrastructure team
• Organisational:
• Weekly technical and management conf calls with all the teams (dev team + integration team + tech team) + follow up from these calls
• Management meetings
• Technical meetings
• Weekly management level meetings
• Communication facilitators + related communication improvements
• Offshore team selection (senior members mostly)
• Offshore training programme improvements
• Crisis escalation investigation + handling
• Accompany Paris members during offshore visits, ensuring success of agenda/visit.
• Methodology/Expertise:
• Definition of Project Development Process with “offshore in mind” and continous improvements (short iterations introduction, usage of JIRA for detailed plannings, acceptance criteria for code delivery, wiki setup, etc).
• Work inside the teams to implement the collaborative development process.
• Quality suggestions + improvements (testing strategy / build improvements for quality + measurements)
• Expertise on build (Maven) + continuous build + testing + collaborative development processes
• Architecture + implementation of regression platform

I'll be going to the TheServerSide Symposium 2004 again this year. I have the privilege to present the following 2 sessions:

• Enterprise builds: This session covers the different architectural concepts required for continuous builds of large projects. We show several strategies and explain how to implement these concepts with different continuous integration tools like Ant, Maven, CruiseControl, etc. The goal is to show what it takes to succeed in implementing an enterprise build. We cover concepts such as environment-dependent builds, binaries dependencies vs source dependencies, snapshot vs reference versions, continuous build strategies, where do tests fit in the build cycle, database strategies for continuous build, team organization related to build, etc.
• Distributed Agile Development (case study): This session will present Pivolis return of experience on a large scale J2EE banking project (approx. 100 persons in development team) developed collaboratively from 2 locations (France and India). We will discuss how we addressed the challenge of migrating from a collocated development setup to a collaborative distributed one. We will also detail how the project was made more agile in the process. We will cover the pitfalls that happened and see how they were resolved.

There's also a nice wiki available for the event.

Once the event is finished, I'll post my slides on this blog.

After discussing with the StatCvs-XML team, we have decided that it would be best that they host the Maven StatCvs plugin on their own site.

This will make it easier for them to improve it and keep it in sync with StatCvs-XML. This is possible thanks to the plugin:download feature of Maven 1.0 rc1/rc2 which allows users to easily install some external plugins. It is also possible to reference a plugin in your own project.xml as a dependency of type plugin .

As part of my day work, I've met CAST Software in France. They are really nice guys. And they have a very good product suite that analyzes application source code and produces different kinds of reports (quality and reverse-engineering/browsing).

The really nice part is their open architecture:

It's nice for the following reasons:

• There can be as many parsers as there are languages, script languages, etc. All data goes to the same database and this data is available to all analyzers. This means that it's possible to define analyzers that act at the level of the full application. For example, you can define some architecture pattern validation. This is the same idea I had some time ago with the PatternTesting project, using AOP to write these rules (I was relying on the Javac parser to perform the source code parsing for me).
• It allows to write browsing tools that show the full flow of the application, from configuration files to database tables

Compare this to existing open source tools (or not open source for some) like Checkstyle, Clirr, PMD, Findbugs, jcoverage, Simian, Clover, etc. They all use their own parsers and more important their own persistence format for storing the parsed data. Even though they almost all offer an XML report format, it's already processed data (as opposed to raw parsing data). Thus it is very hard to reuse the information from these tools to offer a higher level integrated view. It's also a lot of work for these tools to develop all the necessary parsers.

What would be really nice is the creation of an open source project that does the following:

• Define a common storage model (database schema, XML schema, other). It should allow to store historical data too.
• Define a common API to store parsing data
• Define a common API to query parsing data

If such open source project existed, we could have parser projects which could parse Java code, .Net code, Hibernate configuration + code, Struts configs + code, AspectJ Aspects, etc. These parsers would user the common API to store parsed data in the common storage format, thus making the data available to other projects, such as the one mentionned above (Checkstyle, PMD, etc). These projects woud be analyzers and would use the common API to query parsed data and generate reports for their domain of work.

With this, we could build nice analyzers that could completely check for full architecture best practices, across technologies and across frameworks.

Do you think such a project would work?

Note: Maybe CAST should open source this part (storage model) and keep as closed source their added value Parsers and Analyzers? :-)

TheCortex (creator of Clover) has announced a new product called FishEye. It's an SCM mining tool.

They have accepted to run it on Cactus. It's very nice. The things I like particularly:

• RSS feeds on commits, at all directory levels. For example you can subscribe to the feed that monitors changes to the xdocs files if you're interested in documentation updates.
• Annotations (for e.g.: http://fisheye.thecortex.net/viewrep/jakarta-cactus/build.xml?r=1.69)

I've been reminded of this idea by some posts on the Cactus mailing list. I'd venture that at least 50-70% of the the questions asked have already been answered in some form in the past, are available in the Cactus documentation or are easy to answer by some generic rule. I think it could be fun to train a bot to answer these questions. For those that the bot couldn't answer, the user would be redirected to the mailing list where Cactus experts would find the answer and train the bot so that it gets better next time.

It should be possible to have rules that would generate the following kind of dialogue:

• [user] I'm getting an error when running Cactus tests
• [bot] Is the error happening on the client side or the server side?
• [user] I don't know
• [bot] Could you turn logging on and see if the error appears in the client side log or the server side log?
• [user] how do I turn logging on?
• [bot] See the Cactus logging configuration page
• [user] It's happening on the client side
• [bot] Is the error hapenning during the HTTP connection?
• [user] yes
• etc...

It would be cool! My only worry is that it would take too long to create the AIML files. But maybe not. Any experience?

What would be even better would be that the bot would learn from the mailing list posts itself. However, that's probably science fiction at this point in time...

Note: The image was borrowed from Alicebot.org