Introduction

Every project defines a set of rules that all (or most :-)) developers agree on. These rules can be coding conventions, naming conventions or at a higher level architecture decisions or best practices.

Usually these rules are either mentioned verbally or written in a "Developer Guide" (I am personnally using an internal Wiki web site for sharing this best practices knowledge). However, it is not enough. How am I going to verify that I have properly coded against these rules?

So far, there was only one solution: code review. Be it continuously with Pair programming or at some point in time with tech leads or peers performing the review. Wouldn't it be nice if I could have a suite of tests that could automatically check this? In the same spirit a JUnit test suite verifies that code does what it is expected to do. But this time, we would check that not only the code does what it is supposed to do but also that it does it the way we have defined it!

There are several tools available to check coding and naming conventions (See the Resource section), but there are none to perform architecture/design best practices.

... until now ....

Pattern Testing is about providing the means to automatically check for Architecture/Design/Implementation decisions.

Some examples

Here are some examples of automated checks that the PatternTesting framework allows:

• Verify that no calls to any method in our application is allowed to use null,
• Verify that all Avalon components must extend a base AbstractAvalonComponent class,
• Verify that all calls to the database go through a JdbcDataAccess class and that none uses JDBC directly,
• Verify that no System.out.println() are used anywhere (should use the project defined logging facility instead),
• Verify that stateless classes (Thread Safe classes in Avalon terminology, Singleton or "static classes" in other terminologies) are not allowed to set instance variables except at initialisation time,
• Verify that the "control" layer (for exemple for a web application) is only allowed to talk to the "service" layer (implementation of the use cases) and not to the "persistence" layer (for example),
• Verify that any application exception must be a subclass of BusinessException, TechnicalException or CriticalException,
• Verify that the MVC model is applied consistently. For example, verify that any call to the service layer has been through an Action class (if you're using Struts for example),
• Verify that exceptions are only logged at the top level,
• Verify that for any use case, a maximum number of 5 SQL queries to the database is allowed,
• etc...

The power is almost endless...