Next, imagine that the Facade class and the Delegate interface below are part of a bigger system:

Create a matching easymock-test-config.xml (or mockito-test-config.xml).

Now, we have all the bits and pieces that are needed to start writing the integration test. We start simple to make sure that we autowiring and Spring context has been configured correctly:

The test is executed and it passes without any problem.

A second test is added to the same file with some added mock behavior:

Excellent, that test also passes.

Now that we have warmed up, we add a third test to the test class:

As expected, this test also passes without any problem.

Unfortunately, that is not always true. A closer investigation reveals that all tests pass when they are executed individually. When executing all three tests (either from the IDE or from a build tool like Maven), the third test fails unexpectedly:

java.lang.AssertionError:
  Unexpected method call Delegate.doSomethingElse():
        at org.easymock.internal.MockInvocationHandler.invoke(MockInvocationHandler.java:44)
	at org.easymock.internal.ObjectMethodsFilter.invoke(ObjectMethodsFilter.java:85)
	at $Proxy8.doSomethingElse(Unknown Source)
        [...]

This is EasyMock telling us that the mock object is in the wrong state. An EasyMock mock object goes through a series of steps:

1. Initialization - Instantiate the mock object.
2. Record - Record the expectations of the mock object.
3. Replay - Call replay() on the mock object so that it can replay the recorded state.
4. Test - Execute the test assertions.
5. Verify - Call verify() on the mock object to certify that the recorded mock expectations are fulfilled.

In an ordinary unit test, the mock object is thrown away after the verify phase, a new mock instance is created before the next test that can be used to record the new behavior. However, since we are creating a Spring integration test, there is one more thing to consider.

Reused beans

In the testing chapter of the Spring manual it is stated that:

By default, once loaded, the configured ApplicationContext and all of its beans are reused for each test method. Thus the setup cost is incurred only once (per test fixture), and subsequent test execution is much faster.

Consequently, all Spring beans, including mocked beans, will preserve their state between different test methods. The mock object will be in the verify state when the last test begins and not in the record state when delegateMock.doSomethingElse() is called. To solve the problem, we need some mechanism to ensure that the mock object is in a known, well-defined state before each test.

Reset mocks

Both EasyMock and Mockito provide methods to reset() the state of the mocked objects. Normally, resetting mock objects in the middle of a test method is considered to be a potential code smell, because it is likely that you are testing too much and that the test could be refactored into two separate tests accordingly. Nonetheless, resetting the mock instance @Before each test allow us to keep the same mock instance through the entire lifetime of the test class and yet put it in the record state when before each test starts:

When executing all tests in the test class, we see that that the problem has been solved and all tests pass.
For reference, click the link for the full source code of the EasyMock test class (and the Mockito test class).

Comments

You may choose to reset the mocks @After each test, the result will be the same.

The reset() method is called between the different test methods (because of the nature of @After and @Before), so the code smell of calling reset within a test is avoided.

Tests written using Mockito mocks are generally more tolerant for this kind of problem. In contrast to EasyMock, Mockito has no replay() method and no notion of steps. Therefore, it is possible to add additional mock expectations and to replace existing expectations, both after the test has been executed as well as after the result has been verified. Hence, you should always reset your mock objects before each test so that you do not get any accidental mocking behavior.

As a side note, another solution would be to annotate the test class (or all of its test methods) with the @DirtiesContext annotation. This will effectively recreate the entire application context after each test has been executed, causing all Spring beans to be in their initial state and thus the mock beans to be in the record state. Although this will work, there will be a significant performance penalty compared to the suggested reset() and @Before / @After solution, because all beans in the application context will be recreated and re-wired before each test method.

Dependencies

• Spring 3.0.6
• Mockito 1.8.5
• jUnit 4.10
• EasyMock 3.1

References

• Spring Reference Manual - Test Context Management and Caching
• Spring Reference Manual - SpringJunit4ClassRunner
• Spring Reference Manual - ContextConfiguration
• EasyMock
• Mockito

Previous post: Spring Integration Tests, Part I, Creating Mock Objects

(In this post, Mockito has been used for creating mock objects, but the same problem applies to EasyMock as well. You can find the corresponding files if you follow the provided links.)

Test setup

In the following example the SomeClass needs a reference to an instance of the SomeDependency interface:

When writing the integration test, we use the static Mockito.mock(Class classToMock) method to create a mock instance. The straightforward approach would be to let Spring instantiate the mock object with a static factory method in the xml configuration, e.g.

(Corresponding EasyMock config.)

To verify that the beans are created and wired correctly, we write a simple test:

(Same test for EasyMock, just update the @ContextConfiguration with the EasyMock config file.)

To our surprise, the test fails:

[...]
java.lang.IllegalStateException: Failed to load ApplicationContext
Caused by: org.springframework.beans.factory.BeanCreationException:
    Error creating bean with name 'someClass': Injection of autowired dependencies failed;
nested exception is org.springframework.beans.factory.BeanCreationException:
    Could not autowire field: private com.jayway.example.SomeDependency com.jayway.example.SomeClass.someDependency;
nested exception is org.springframework.beans.factory.NoSuchBeanDefinitionException:
    No matching bean of type [com.jayway.example.SomeDependency] found for dependency:
    expected at least 1 bean which qualifies as autowire candidate for this dependency.
    Dependency annotations: {@org.springframework.beans.factory.annotation.Autowired(required=true)}
[...]

Explanation

In order to find a solution to the problem, we need to understand Spring's initialization process:

1. Load bean definitions.
   This step includes scanning the application context XML files, scanning packages defined by component-scan, and loading the bean definitions found into the bean factory. (BeanFactoryPostProcessors such as the PropertyPlaceHolderConfigurer may be called to update the bean definitions.)
2. Instantiate beans and store them in the application context.
   The bean factory creates the bean from the bean definitions. Bean dependencies get injected.
3. Bean post processing.
   All initializing methods (e.g. annotated with @PostConstruct, init-methods declared in the XML and the afterPropertiesSet() method will execute. Annotations such as @Required will be validated. Dynamic proxies in an AOP environment will be created and so on.

The problem that we see occurs due to a corner case in the first two steps. When the bean definition is created Spring scans through the application context XML file. It finds the declaration of the mock bean and a reflective call is made to find out the return type of the method defined by the factory-method declaration in an attempt to determine the bean's type. The return type of this method is declared as the formal type parameter <T> (remember that we use the Mockito.mock(Class<T> classToMock) as factory method). Consequently, the bean definition of someDependencyMock will be of java.lang.Object and not SomeDependency as one would think.

In the second step, the someClass bean is instantiated. Springs discovers the @Autowired annotation and tries to fetch an existing SomeDependency bean from the application context. None has yet been created, so the bean factory proceeds and looks for suitable bean definition in order to create an instance of the requested bean on the fly. This operation fails because the bean definition of someDependency is mapped to java.lang.Object. At this point, Spring bails out and throws the NoSuchBeanDefinitionException.

FactoryBean to the rescue

The problem is solved by implementing a custom FactoryBean that can be used whenever we need to mock an object:

(In the EasyMockFactoryBean, I have added an enum to define the type of mock object.)

Next, the Spring test config is updated to use the factory bean:

(Corresponding EasyMock config.)

Spring will still instantiate the beans in the order that they were declared in the mockito-test-config.xml, i.e. starting by creating an instance of SomeClass and then attempt to inject an instance of a SomeDependency into it before any has been created. The good news is that bean factory will scan through all declared FactoryBeans, calls its getObjectType() method, and if the returned type is correct, call its getObject() which should return an instance of the requested type.

Alternative solution

There is another more brittle solution to the problem. By simply changing the order of the tags in the initial application context, e.g. putting the bean declaration that defines the mock above the component scan, will cause the test to pass. The bean definition will still be wrong in the sense that the someDependencyMock will be defined as a java.lang.Object, but there is another important difference. In this case, the bean factory will invoke the Mockito.mock(Class<T> classToMock) method with SomeDependency as parameter causing the someDependencyMock bean to be created and subsequently stored in the application context. Later, the someClass bean is created and the dependency can obtained from the application context when requested by the bean factory and the wiring of the beans will succeed. However, making sure that the order of the bean declarations in the XML is always correct may neither be simple nor obvious, and it will get increasingly more difficult the more beans you add to the configuration.

Disclaimer

As stated in the in the first paragraph, I would only consider this solution for integration tests because of performance reasons. The application context itself adds some overhead, but the big performance hit is to create and wire all beans that are associated with it. When writing unit tests there is no need for this, so you could revert to constructor or setter dependency injection, Spring's ReflectionTestUtils.setField(), PowerMock's Whitebox.setInternalState(), Mockito's @InjectMocks or similar techniques.

Acknowledgements

Thanks to Wilhelm Kleu at stack overflow for suggesting the solution and to Mattias Hellborg Arthursson for valuable discussions.

Dependencies

• Spring 3.0.6
• Mockito 1.8.5
• jUnit 4.10
• EasyMock 3.1

References

• Spring Reference Manual - Static Factory Method
• Spring Reference Manual - FactoryBean
• Spring Reference Manual - Integration Testing
• Mockito
• EasyMock

Next post: Spring Integration Tests, Part II, Using Mock Objects

In some environments user's home directory is located on the mapped network drive which in unacceptable for IntelliJ IDEA. You'll notice the huge performance degradation.

What is the problem?

There are some good motives for keeping the home directory mounted to a network folder rather than on the local hard drive. For example, all user settings and user documents can be backed up centrally, and the user could potentially log in to any computer and have the same user environment. However, there are also some drawbacks. Depending on how the home folder is configured, there will either be a remote network call for each file access, or the file changes will be executed as a batch job at scheduled intervals or specific events such as logging off the computer.

The second part of the problem is that IntelliJ IDEA produces quite a lot of data, typically several hundred megabytes, besides the anticipated artifacts. The data consists of IDE plugins, configuration files, log files, but the vast majority is internal cache files. By default, the data is written to a hidden .IntelliJIdea10/ folder in your home directory.

If you combine these two factors, the performance will suffer. How much depends on the bandwidth of your network, something that I became painfully aware of when I logged in remotely to the customer's network via a slow VPN connection.

Solution

Avoid network overhead by configuring IntelliJ IDEA to cache data on your local computer instead of in your home folder. A recent customer used Windows XP as their working environment, the instructions below are based on that experience.

1. Create a new directory on a local harddrive that IntelliJ IDEA can use, e.g. C:/.IntelliJIdea10/. Hint, you cannot create a library starting with a "." from Windows Explorer, you have to use the mkdir command from the terminal.
2. Locate the idea.properties file in the bin directory in IntelliJ IDEA's installation directory. The default location is C:\Program Files\JetBrains\IntelliJ IDEA Community Edition 10.5.1\bin.
3. Change the relevant properties to point to the recently created directory:

   # path to IDEA config folder. Make sure you're using forward slashes
   idea.config.path=C:/.IntelliJIdea10/config
   
   # path to IDEA system folder. Make sure you're using forward slashes
   idea.system.path=C:/.IntelliJIdea10/system
   
   # path to user installed plugins folder. Make sure you're using forward slashes
   idea.plugins.path=C:/.IntelliJIdea10/config/plugins
   

Considerations

Consider not to change the idea.config.path property if you are using several different computers and you would like to have the same configuration on all machines. Additionally, if you are using IntelliJ IDEA Ultimate, i.e. the commercial version of the tool, you should also make a cautious decision about whether or not to keep this property unchanged, because the license file is stored in the denoted directory. On the other hand, if you always use the same computer you might as well change this property together with the other properties, so that all IntelliJ IDEA files are stored in the same location.

References

• IDEA files location: http://devnet.jetbrains.net/docs/DOC-181
• IDEA license key: http://devnet.jetbrains.net/docs/DOC-200

• Three different FTP protocols should be supported, namely FTP, FTPS and SFTP
• It should be possible to transmit different files to several different servers
• The files to be sent were generated in runtime, they had different file names and were stored in different directories

Basically, I should implement the following interface:

FtpSender.java

public interface FtpSender {

    /**
     * Uses the {@code ftpProperties} to transmit the provided {@code file} to a remote server
     *
     * @param ftpProperties The FTP properties of the remote server
     * @param file The file to transmit
     */
    void sendFile(FtpProperties ftpProperties, File file);
}

where the FtpProperties was another interface:

FtpProperties.java

public interface FtpProperties {

    /**
     * Gets the protocol
     * @return One of {@code ftp}, {@code ftps} or {@code sftp}
     */
    String getProtocol();

    /**
     * Gets the user name
     * @return The name of the user
     */
    String getUserName();

    /**
     * Gets the password
     * @return The password
     */
    String getPassword();

    /**
     * Gets the FTP host
     * @return The FTP host
     */
    String getHost();

    /**
     * Gets the name of the directory on the server where the file will be transferred
     * @return The name of the remote directory
     */
    String getRemoteDirectory();

    /**
     * Gets the passive mode, e.g. if the server is behind a firewall
     * @return whether or not passive mode should be used
     */
    boolean getPassiveMode();
}

Rather than implementing the entire FTP client from scratch, I investigated the capabilities of existing frameworks. Most solutions recommend using an existing FTP framework such as Apache Commons / Jakarta Commons Net for FTP and FTPS and then wrap it in a SSH layer like Jsch / Java Secure Channel for SFTP. However, soon I discovered Apache Camel, "a powerful open source integration framework based on known Enterprise Integration Patterns with powerful Bean Integration" (their words). They support a various range of components, anything from XQuery and Atom to XSLT and SQL, just to name a few. To my luck, they also support all three FTP protocols that I needed.

Fundamentals

What does the Camel FTP API look like? In its basic form it is a little more than a one-liner:

FtpRouteBuilder.java

public class FtpRouteBuilder extends RouteBuilder {

    @Override
    public void configure() throws Exception {
        from("file://localDirectory").to("ftp://user@host.com/remoteDirectory?password=secret&passiveMode=true");
    }
}

So what is going on here? The RouteBuilder is one of Camel's core classes that defines the Camel specific DSL. In this example, a Route from the localDirectory to a remoteDirectory over FTP with the provided credentials has been created. As can be seen, it is easy to create and configure different endpoints using String URIs. It should also be mentioned that it is possible to fetch files from the remote FTP server by swapping the URIs in the to and from methods.

A few more lines are needed to activate the route:

public static void main(String[]args) throws Exception {
    CamelContext camelContext = new DefaultCamelContext();
    try {
        camelContext.addRoutes(new FtpRouteBuilder());
        camelContext.start();
        // do other stuff...
    }
    finally {
        camelContext.stop();
    }
}

A CamelContext is created for managing the route. The previously described FtpRouteBuilder is instantiated and added to the camelContext which is subsequently started. As a consequence, any file that is placed in the "localDirectory" folder will be automatically transferred to the "remoteDirectory" of the FTP server while the program is running.

Adding Configurability

The requirement of supporting different FTP protocols is solved by changing the URI from ftp:// to ftps:// or sftp:// respectively. It is just as easy to fulfill the second requirement of multiple server support by changing the host, user, port and other parameters of the URI. Likewise, additional settings may be configured by adding more options if needed, see the Camel FTP documentation.

Adding Dynamism

The last challenge was to add the dynamic support of selecting source files and destination servers during runtime. The easiest solution is to use another of Camel's base classes, the ProducerTemplate. Again, the solution is a one-liner:

producerTemplate.sendBodyAndHeader("ftp://user@host.com/remoteDirectory?password=secret", file, Exchange.FILE_NAME, file.getName());

The sendBodyAndHeader() method name reveals a glimpse of Camel's underlying messaging architecture. The parameters used are the destination URI with additional options, the message body, i.e. the File to be sent, a message header parameter that identifies the last parameter as the name of the file it will have on the remote server once it has been transferred.

Spring Integration

With some refactoring and a little Spring magic we have all the bits and pieces needed to implement the previously defined FtpSender interface:

FtpSenderImpl.java

@Service
class FtpSenderImpl implements FtpSender {

    /** Camel URI, format is ftp://user@host/fileName?password=secret&passiveMode=true */
    private static final String CAMEL_FTP_PATTERN = "{0}://{1}@{2}/{3}?password={4}&passiveMode={5}";

    private final ProducerTemplate producerTemplate;

    /**
      * Constructor
      * @param producerTemplate The producer template to be be used
      */
    @Autowired
    FtpSenderImpl(ProducerTemplate producerTemplate) {
        this.producerTemplate = producerTemplate;
    }

    @Override
    public void sendFile(FtpProperties ftpProperties, File file) throws RuntimeException {
        producerTemplate.sendBodyAndHeader(createFtpUri(ftpProperties), file, Exchange.FILE_NAME, fileName);
    }

    /**
      * Creates a Camel FTP URI based on the provided FTP properties
      * @param ftpProperties The properties to be used
      */
    private String createFtpUri(FtpProperties ftpProperties) {
        return MessageFormat.format(CAMEL_FTP_PATTERN,
                ftpProperties.getProtocol(),
                ftpProperties.getUserName(),
                ftpProperties.getHost(),
                ftpProperties.getRemoteDirectory(),
                ftpProperties.getPassword(),
                ftpProperties.getPassiveMode());
    }
}

Using the Camel namespace, the required plumbing work is delegated to the Spring application config:

spring-config.xml

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:context="http://www.springframework.org/schema/context"
       xmlns:p="http://www.springframework.org/schema/p"
       xmlns:camel="http://camel.apache.org/schema/spring"
       xsi:schemaLocation="
		http://www.springframework.org/schema/beans   http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
		http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-3.0.xsd
		http://camel.apache.org/schema/spring http://camel.apache.org/schema/spring/camel-spring.xsd">

    <!-- Let Spring create the Camel context and the Camel template, including lifecycle management such as starting and stopping them -->
    <camel:camelContext id="camelContext">
        <camel:template id="camelTemplate" />
    </camel:camelContext>

    <!-- Use Spring component scan to find the FtpSenderImpl implementation -->
    <context:component-scan base-package="com.jayway.ftp" />

</beans>

Conclusions

Camel and Spring provide a simple, yet configurable, way of implementing a dynamic FTP client.

Acknowledgments

Thanks to Claus Ibsen and other members of the Apache Camel Forums for providing valuable and rapid support.

Glossary

• FTP File Transfer Protocol
• FTPS FTP Secure is an extension to FTP that adds support for the TLS, Transport Layer Security, and the SSL, Secure Sockets Layer, cryptographic protocols
• SFTP SSH File Transfer Protocol, i.e. FTP over the Secure Shell protocol

References

Camel API
Camel Components
Camel FTP
Camel ProducerTemplate
Camel Spring
Camel ProducerTemplate and Spring
Camel Enterprise Integration Patterns
Camel Forums

Recipe

So how can you shape up the code? Yet better, how can you prevent that the code turns into spaghetti in the first place? One way of looking at architectural requirements is that they are crosscutting concerns that are scattered throughout the software. As such, they can be implemented and enforced by using AOP, aspect-oriented programming. The recipe is pretty straight forward:

1. Implement a pointcut that finds the violations of your architecture.
2. Implement an advice that notifies you about the violations.
3. Wrap the pointcut and the advice into an aspect.
4. Refactor your code and exercise your aspect until all architectural violations have been removed.

Example

This recipe of using aspects as a way of enforcing architectural rules can be applied in any kind of project, for example to enforce the MVC pattern, to separate one domain from another in a DDD project and so on. In this particular example, the application is based on a three layer architecture. The top layer being the GUI layer, the middle layer is the service layer and then there is the DAO layer in the bottom. Each layer has a separate package, as stated below:

SomeGui.java package com.jayway.application.gui; /** Simplistic GUI */ public interface SomeGui { /** Renders the GUI */ void render(); } SomeService.java package com.jayway.application.service; /** Simplistic Service */ public interface SomeService { /** Executes some service */ void service(); } SomeDao.java package com.jayway.application.dao; /** Simplistic DAO */ public interface SomeDao { /** * Finds something in the DAO * @return some data */ public Object find(); }

Architectural Rules

Four architectural rules have been defined:

1. The GUI layer must not access the DAO layer
2. The Service layer must not access the GUI layer
3. The DAO layer must not access the Service layer
4. The DAO layer must not access the GUI layer

These rules are the candidates for defining the pointcuts that should be implemented. An example of code that would violate the first rule is:

BadGuiImpl.java

/**
 * Bad GUI implementation that violates the architectural rule
 * because it calls a method in the DAO layer
 */
public class BadGuiImpl implements SomeGui {

    private SomeService someService;
    private SomeDao someDao;

    @Override
    public void render() {
        // it is ok to use the service...
        someService.service();

        // ...but it is not ok to call the DAO directly
        someDao.find();    

        // more rendering
    }
}

Using AspectJ, two pointcuts have been implemented to trap the violation. Additionally, AspectJ also provides the @DeclareError annotation that can be used for the advice implementation. Finally, an aspect that comprises the pointcuts and the advice has been created:

ArchitecturalEnforcement.java

/**
 * The aspect that is responsible for architecture enforcement:
 * The GUI layer must not access the DAO layer.
 */
@Aspect
public class ArchitecturalEnforcement {

    /** Pointcut for finding join points inside the GUI layer */
    @Pointcut("within(*..*gui..*)")
    public void withinGui() {}

    /** Pointcut for finding method calls to the DAO layer */
    @Pointcut("call(* *..*.dao..*(..))")
    public void callDao(){}

    /** Advice that defines an error when a GUI method calls a method in the DAO layer */
    @DeclareError("withinGui() && callDao()")
    private static final String GUI_MUST_NOT_USE_DAO = "GUI must not access DAO";
}

Exercise the Aspect

How should you use your aspects to enforce the architecture? Since we now have the tools to automate the architectural review, you should use them frequently. AspectJ has support for compile time weaving which means that the advices can be woven into their corresponding join points during source code compilation. The aspectj-maven-plugin can do it for you:

pom.xml

<dependencies>
    <dependency>
        <groupId>org.aspectj</groupId>
        <artifactId>aspectjrt</artifactId>
        <version>1.6.7</version>
    </dependency>
</dependencies>
    ...
<build>
    <plugins>
        <plugin>
            <groupId>org.codehaus.mojo</groupId>
            <artifactId>aspectj-maven-plugin</artifactId>
            <version>1.3</version>
            <configuration>
                <complianceLevel>1.6</complianceLevel>
            </configuration>
            <executions>
                <execution>
                    <goals>
                        <goal>compile</goal>   <!-- Weaves the main classes -->
                        <goal>test-compile</goal>   <!-- Weaves the test classes -->
                    </goals>
                </execution>
            </executions>
        </plugin>
    </plugins>
</build>

Result

If you have put everything together correctly, you will find that you will get a compile time error when you attempt to execute mvn compile:

[[INFO] [aspectj:compile {execution: default}]
[ERROR] "GUI must not access DAO"
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Compiler errors:
error at someDao.find();
^^^^^^^^^^^^^^
/home/mattias/architectural-enforcement/src/main/java/com/jayway/application/gui/BadGuiImpl.java:20:0::0 "GUI must not access DAO"
	see also: /home/mattias/architectural-enforcement/src/main/java/com/jayway/application/aspects/ArchitecturalEnforcement.java:1::0

You can also see the error in your Eclipse IDE if you are using the AJDT - AspectJ Development Tools plugin:

Notably, the implementation above was just one of the stated rules. The implementation of all four rules together with some examples that break them and the Maven pom file are available for download for your convenience.

Considerations

There are some things that you may want to consider before introducing aspects as a tool for automated architectural enforcement:

• Error or Warning

  A compile time error is a powerful tool that prevents the developer to commit any code that does not conform to the architectural rules (presumed, of course, that the code is actually compiled before being checked in). A less brutal way of introducing aspects as a part of architectural review is to use the @DeclareWarning annotation rather than the @DeclareError that was used in the example. Consequently, any architectural offenders will be punished with a compiler warning rather than a compiler error.

• Performance

  The compile time will increase when you add more architectural rules that should be obeyed, that is when you add more pointcuts. Likewise, the compile time will also increase when your code base grows, because of the increasing number of join points in the code. By limiting the aspectj-maven-plugin to certain maven profiles, the developers only have to verify that their particular module conforms to the rules. Alternatively, all modules can be verified by the integration server during nightly builds. The drawback is that the advantage of having the architecture enforced before the code is committed to the version control system will be lost.

• Limitation

  The aspect above can only trap architectural violations when a method is being called. Regrettably, any unused declaration that would violate the architecture will pass unnoticed:

  AnotherBadGuiImpl.java

  package com.jayway.application.gui;
  
  import com.jayway.application.dao.SomeDao;
  
  /**
   * Another bad GUI implementation that violates the architectural rule
   * because it has references to the DAO layer.
   * However, these errors will remain undetected by AspectJ.
   */
  public class AnotherBadGuiImpl implements SomeGui {
  
      /** Unused DAO reference */
      private SomeDao someDao;
  
      /**
       * Setter method that for some obscure reason adds a DAO to the GUI
       * @param someDao A DAO reference that is not found by the pointcut
       */
      public void setDao(SomeDao someDao) {
          this.someDao = someDao;
      }
  
      @Override
      public void render() {
          // valid gui rendering that does not use the dao reference
      }
  }
  

  One solution is to create another pointcut, such as @Pointcut("set(*..*.*dao*..* *)"), that traps the assignment of the someDao member variable.

Wrap Up

Education of the developers and repeated manual code reviews have been the traditional ways of improving software architecture. Unfortunately, it is not good enough. It is always a good idea to have skilled employees, but even experts do make mistakes. After all, people that manually review code are only humans, which implies that the reviews are resource demanding, yet error prone. With the powerful tools of today's IDEs it is very easy to do refactoring hastily and soon the code starts to degrade. With a proper implementation, AspectJ offers one way to automate architectural enforcement, hereby preventing architectural drift.

Edit

2010-04-16: Added screenshot of AJDT plugin and an example of how the "set" pointcut can be used.

Unit testing is a very powerful tool that should be included in every developer's toolbox. Unfortunately, this has not always been the case, especially not among MIDlet developers. One reason is that JavaME projects usually are small (compared to Java SE projects), which implies that manual testing could be enough. However, as soon as you start developing production code you really should consider to automate your tests by developing your own test suite.

Some of you may have played around with JMUnit project. It is a nice framework that allows you to write tests that can be transferred to your phone or emulator and you will see the test result on the display. Alternatively, the tests can be executed by Ant. Still, there are some limitations that you cannot bypass:

• Because of CLDC's lack of reflection, you cannot benefit from the powers of jUnit 4.x.
• You cannot create mock objects. This means that if a class has dependencies to other classes you will perform an integration test rather than a unit test.
• The turn around time for test, debug and retest, is significantly larger compared to Java SE unit testing, especially if you are executing the test on the phone.

No offence to the JMUnit guys, they are restricted by the limitations of the CLDC VM and the fact that you need a target device (a phone or an emulator) to run the tests on. But maybe there is a workaround to solve these problems? With some tricks, it is possible to unit test your JavaME code in the same way as you would unit test your Java SE code. In other words, you can execute the tests on the PC side without deploying the tests to an emulator or a phone.

PowerMock

One part of the solution is to mock any platform dependencies. Previously, it was an awkward job to do, but the introduction of PowerMock allows us to mock the many static methods in MIDP and CLDC. The easiest way to get started with powermock is to download the powermock-1.2-with-dependencies.zip. In another post I have explained how PowerMock can be used to mock the RecordStore in MIDP.

Project configuration

If you are using Eclipse, you need two projects, one for your phone application and the other your test code. This is because different projects can have different java compiler settings.

• Create a MIDlet project. This is your phone application. Make sure that the "Java Compiler" compliance level is "1.3".
• Create a Java project. This is the test project where you will write your tests. Make sure that the "Java Compiler" compliance level is set to "1.6" (or to whatever JDK version you have installed).
  • Add the midlet project you just created to "Required projects" in the "Java Build Path" setting.
  • Add the PowerMock jar files and their dependencies to "Libraries" in the "Java Build Path" setting.

In the MIDlet project, you write your application code and in the java test project you write your java jUnit tests. Normal package protection rules apply, so you should consider to reuse the package name from the class in the midlet project you would like to test when you are writing the test class in the java project.

Automation

Naturally, it is possible to automate the test by using build tools. Here is an example using of an Ant build.xml file:

 
<?xml version="1.0" encoding="UTF-8"?>
<project name="Example" default="test" basedir=".">
<property name="midlet.project.home" value="C:/your_workspace/MidletProject" />
<property name="test.project.home" value="C:/your_workspace/MidletProjectTest" />
<property name="powermock.home" value="C:/your_path/powermock-1.2" />
<property name="wtk.home" value="C:/WTK2.5.2" />
<property name="src.dir" value="${midlet.project.home}/src" />
<property name="test.src.dir" value="${test.project.home}/src" />
<property name="bin.dir" value="classes" />
<property name="test.bin.dir" value="test-classes" />
<property name="test.result.dir" value="test-result" />
<path id="midlet.dependencies">
		<fileset dir="${wtk.home}/lib">
			<include name="*.jar" />
		</fileset>
	</path>
<path id="test.dependencies">
<pathelement location="${bin.dir}" />
<path refid="midlet.dependencies" />
		<fileset dir="${powermock.home}" />
	</path>
 
	<target name="clean">
		<delete dir="${bin.dir}" />
		<delete dir="${test.bin.dir}" />
		<delete dir="${test.result.dir}" />
	</target>
 
	<target name="compile">
		<mkdir dir="${bin.dir}" />
		<javac srcdir="${src.dir}"
			destdir="${bin.dir}"
			source="1.3"
			target="1.1"
			classpathref="midlet.dependencies" />
	</target>
 
	<target name="compile-tests" depends="compile">
		<mkdir dir="${test.bin.dir}" />
		<javac srcdir="${test.src.dir}"
			destdir="${test.bin.dir}"
			classpathref="test.dependencies" />
	</target>
 
	<target name="test" depends="clean, compile-tests">
		<mkdir dir="${test.result.dir}" />
		<junit printsummary="yes">
			<classpath refid="test.dependencies" />
			<classpath path="${test.bin.dir}" />
<formatter type="plain" />
			<batchtest fork="yes" todir="${test.result.dir}">
				<fileset dir="${test.src.dir}" />
			</batchtest>
		</junit>
	</target>
</project>
 

Now your project configuration is setup and you can test your MIDlet code in the same way as you would test your Java SE code.

What's next?

If you are a dedicated MIDlet developer you would probably like to add more build targets later on to preverify, obfuscate, sign, package and deploy your MIDlet.

You should also consider using a continuous integration server together with your version control system and configure it to run your test suite whenever the code has been changed. Depending on the server you choose, you may also find that it may be used to present result from static code analysis tools, code coverage, code metrics and so on.

PowerMock is a mocking framework that claims to have almost supernatural powers. According to its documentation it is able to mock both static and private methods, final classes, and other nasty things that would be insurmountable obstacles for other mock frameworks. As a result, it has been stated that it should be able to mock the MIDP RecordStore, but so far I have not seen a working example. I accepted the challenge.

Getting started

I decided that writing a unit test was the best way to get started. After all, mocking is usually used together with unit testing.
In order to use RecordStore you must first open it. According to the javadoc of RecordStore, the method to be used is: public static RecordStore openRecordStore(String recordStoreName, boolean createIfNecessary).
A static method that returns an instance of the RecordStore object. Following the "Mocking static methods" guidelines on the PowerMock web site, it seemed to be a pretty straight forward task:

1. Use the @RunWith annotation at the class-level of the test case.
2. Use the @PrepareForTest annotation at the class-level of the test case.
3. Use PowerMock.mockStatic() to mock all methods of this class.
4. Use PowerMock.replay() to change the class to replay mode.
5. Use PowerMock.verify() to change the class to verify mode.

Ok, a little more complicated than my ordinary EasyMock setup, but nothing to really worry about. In my case, I also needed to create a mock object of the RecordStore class itself because of the return value of the openRecordStore() method.

The setback

To my disappointment, my test failed with an ExceptionInInitializerError. I studied the code thoroughly to make sure that I had followed the instructions, but I concluded that error resided elsewhere. A closer look at the failure trace revealed:

[...]
Caused by: java.lang.UnsupportedOperationException: getSlowingFactor is native
at javax.microedition.rms.RecordStore.getSlowingFactor(RecordStore.java)
at javax.microedition.rms.RecordStore.(RecordStore.java:2414)
[...]

Hmm, that is strange... According to the API, there should be no getSlowingFactor() in RecordStore? And it seems like it is called by the class initializer? When searching for an answer it seemed like this problem occurs if you have not configured the preverifier correctly. It sort of makes sense, I am not using a preverifier at all in my project and I did not like the idea of introducing one.

The solution

Returning to the PowerMock documentation, I discovered instructions how to "Suppressing Unwanted Behavior", maybe this was the way forward? Soon, I found the annotation @SuppressStaticInitializationFor, I added it to my test case and voilà, I had successfully mocked the RecordStore!

Reference code

You can find the code needed to mock the RecordStore below. If you find it interesting, you can download a more complex example where a class that uses RecordStore for persistent storage is unit tested with aid of PowerMock.

 
import static org.easymock.EasyMock.expect;
import static org.easymock.classextension.EasyMock.createMock;
import static org.junit.Assert.assertEquals;
import javax.microedition.rms.RecordStore;
import javax.microedition.rms.RecordStoreException;
 
import org.junit.Test;
import org.junit.runner.RunWith;
import org.powermock.api.easymock.PowerMock;
import org.powermock.core.classloader.annotations.PrepareForTest;
import org.powermock.core.classloader.annotations.SuppressStaticInitializationFor;
import org.powermock.modules.junit4.PowerMockRunner;
 
@RunWith(PowerMockRunner.class)
@PrepareForTest(RecordStore.class)
@SuppressStaticInitializationFor("javax.microedition.rms.RecordStore")
public class RecordStoreMockTest {
 
	@Test
	public void testCreateRecordStoreMock() throws RecordStoreException {
		String recordStoreName = "record_store_name";
 
		// Create mocks
		PowerMock.mockStatic(RecordStore.class);
		RecordStore recordStoreMock = createMock(RecordStore.class);
 
		// Record behavior
		expect(RecordStore.openRecordStore(recordStoreName, true)).andReturn(
				recordStoreMock);
 
		// Replay behavior
		PowerMock.replay(RecordStore.class);
 
		// Execute test and verify result
		assertEquals(recordStoreMock, RecordStore.openRecordStore(recordStoreName, true));
		PowerMock.verify(RecordStore.class);
	}
}
 

The Conference

During the last three years, Øredev has grown from a promising initiative to one of
the biggest IT-conferences in Scandinavia. During this year’s event, over 800 visitors
attended more than 100 events. To handle the increasing crowd, the conference was
held at a new location, MalmöMässan, which offered bigger and better conference
halls and more space for the show floor.
The location also offered a lack of heating in some rooms, which in the Swedish
November weather translates into cold conference halls. People kept chugging cof-
fee to keep warm, and everybody wished Oracle would hand out blankets instead
of bottle chillers.
As many as nine parallel tracks were available this year. Back from last year were:
Java, .NET, Methods & Tools, etc. In addition to these, Øredev 2007 offered several
new tracks such as Architecture, Case Studies and more. Especially refreshing were
the User Experience sessions, an important yet often overlooked topic.
Further indicating the growing status of the conference was the number of no-
table speakers that participated this year. The list included big names such as Andy
Hunt, Joel Spolsky, Kevlin Henney, James Coplien, Dan North, and Dr. Jeff Suth-
erland.
At the exhibition floor 26 companies were fighting for the visitors attention. The
innovation in terms of advertising varied ranging from plain old booths with posters
and free pens to elaborate coding competitions with iPods to win.
In spite of being an IT conference, there was only one robot on the show floor,
the SMErobot from Lund. Completely implemented in Java the robot was solving
sudoku and carving in wood taking it’s instructions from a piece of Anoto paper. As
a request for new functionality we would like to see the robot performing massage.
Should not be too hard to implement, considering that the platform is Java based.

The keynotes

Being a keynote speaker is always special. There are high expectations of both vi-
sions and entertainment. Being recognized in the business, you would better have a
good presentation up your sleeve. Although some of this years speeches contained
more wittiness than visions, there were three enjoyable keynotes to listen to.

Andy Hunt: How hard can it be?

Andy Hunt is well known as one of the 17 founders of the Agile Alliance and the
co-founder of the Pragmatic bookshelf.
During his opening keynote, Hunt asked the audience the infamous question
“How hard can it be?”. He answered the question himself by stating that there are
two different types of complexity, namely essential complexity and accidental com-
plexity. Essential complexity is the complexity required to do a job. It is something
that we all have to live with, some things are hard to achieve by nature. Accidental
complexity or unnecessary complexity on the other hand is something that is arti-
ficial. It should and can be prevented if it is recognized accordingly. There are many
possible reasons for accidental complexity; prejudices or ignorance, stress or lack of
motivation or even just bad luck. Regardless reason, the recipe to avoid accidental
complexity is always the same: rely on reliable things, make a purposeful plan and
stick to it.

Dan North: No Best Practices: Methodology for thinkers

Dan North is a renowned speaker from other conferences like JAOO, Agile and
OOPSLA in topics like learning theory and behaviour-driven design. The keynote
North gave at Øredev showed he has a rightful reputation.
As the title indicates, the main mantra in North’s presentation was that there is
no such thing as best practices. As he presented this theory the feeling was similar to

the scene in Dead Poet’s Society where the teacher asks his students to rip out the
first chapter of their text books.
As a basis for his claim, North explained the Dreyfus Model of Skill Acquisi-
tion. The Dreyfus Model is in itself an interesting topic and describes five different
stages in learning: Novice, Advanced Beginner, Competent, Proficient and Expert.
The novice is the stage of an absolute beginner who relies on rules and guidance to
be able to function whereas the Expert works based off intuition and knowledge at
the subconscious level that has been gathered through many years of work. The in-
teresting part is that the efficiency of people at the expert level is severely reduced if
they are bounded by the safe environments such as a “best practice” that the novice
needs. Best practices are in other words obstructing the people who are the best, the
experts, from doing their job effectively.

Joel Spolsky: Developing Great Software

Joel Spolsky has reached his biggest audience through his website joelonsoftware.
com. He is the founder of Fog Creek Software and has created FogBugz, a popular
project management system.
Ten seconds into his seminar, Spolsky immediately showed that he belongs to the
rare selection of people that knows how to make a powerpoint presentation that is
more than just a bunch of slides. As Spolsky brought up a huge picture of Victoria
Beckham on the first page, you knew that you were in for a treat. The topic of the
speech was the importance of good looking software.
Spolsky argued that no matter how good your software is, you will not reach
mass market unless it looks good. He illustrated this through various comparisons
of popular products. Particularly entertaining was the part where he brought up a
Windows XP simulation created entirely within the powerpoint presentation. One
could argue whether that was a good example to bring up in the context of his
speech. Windows is a product that doesn’t necessarily look good compared to one
of its main competitors (OS X), yet has a vastly larger market share. Nevertheless,
the display was impressive and produced lots of laughs from the audience as Spolsky
struggled with various pop-ups and failures in his powerpoint-driven “Windows”.
Even though his presentation clearly was more about entertainment than anything
else, he managed to state an important point: software needs to look good to suc-
ceed!

Sharing knowledge

Besides the keynotes the real knowledge sharing was made in the around 80 semi-
nars and in the exhibition hall.
Following the Java track we witnessed the official launch of the Qi4J framework,
introducing Composite Oriented programming, redefining the way we use OOP
today. The new concepts that Qi4J bring are not obvious, even to somebody with
extensive Java experience. We are hoping that Qi4J for dummies will turn up in our
local book store soon.
We also got a first glimpse of Java FX Script, the new GUI framework from
SUN. It has been developed to provide an alternative to the clunky looking Swing
interfaces. Although not yet mature, it is meant to compete with technologies like
Flash and Silverlight.
Another interesting seminar was delivered by Neo Technology, showing us a new
and faster way to store data. Briefly, they have implemented a database using a net-
base, i.e. networks in Java rather than database tables. During the presentation, they
performed a simulated Facebook relation search outclassing a traditional database
by the magnitude of a million.
Identifying some of the trends using Java as a platform rather than as a language is
becoming big. More lightweight languages and scripts such as JRuby on Rails make
use of the Java platform. Domain Driven Design and Web 2.0 (still) were other buz-
zwords that floated around in the lecture halls. As always at Øredev there was a big
focus on open source. The business is changing more towards using and developing
open source frameworks incorporating community thinking into their development
process. There were several seminars that both presented new functionality within
existing frameworks and showed smart ways of using existing technologies. One
example was the demonstration of the new batch framework in Spring.
Sitting in on some of the test and project management seminars a couple of key-
words emerged over and over again, namely “agile” and “test driven”. Even though
most people know that these methods increase productivity and quality of the code,
a quick audience survey showed that there are still few development teams that
actually have incorporated these into their processes. Apparently, it is still tricky to
convince your boss that agile development actually does bring huge winnings.

Evening activities

After a full day of new knowledge, inspiring lectures and networking the stage was
taken by the UK stand-up comedian Shazia Mirza. Mirza is a highly acclaimed co-
median and a columnist for the New Statesman. She was recently profiled on CBS
‘60 minutes and has performed all over Europe and USA. Mirza put on a great show
not being the least shy or politically correct, even though she was, as she put it, “the
only Asian woman amongst 600 computer nerds”.
Some great laughs later it was back to business with late evening “Birds Of Feath-
ers” (BOFs), making full flown eagles out of the feathers of knowledge we had been
given during the conference. Some of us joined Owen Taylor at Gigaspaces, making
a complete Gigaspace storage run on our laptops. We were given a chance to try
out this new technology together with one of it’s creators, enabling us to bring the
installation back home for further experiments and tests. We got (and still have) a
good possibility to look under the hood of the magic this product brings, at least that
is promised by Taylor.
For the people that had enough of birds and feathers there was more entertain-
ment from our own band Rockway.

Workshops

There were many that sought a hands-on experience with the material that was
presented during Øredev, and all participants were given a chance to follow up the
lectures with a variety of workshops. The most popular one was the full Scrum certi-
fication course held by Dr Jeff Sutherland, one of the main creators and preachers of
the Scrum methodology. Another popular workshop was a full day of Qi4J training
allowing programmers to try out the newly launched framework. Andy Hunt also
followed up his lecture on refactoring wetware, i.e. the human mind, with a three
hour workshops, allowing the participants to try out some of the concepts that will
increase productivity and make more efficient use of our brain cells. Hunt presented
a bunch of mind tricks that would have come very handy earlier in the conference.

Finally

The yearly Øredev conference is a source of inspiration to an increasing amount of
people. As an employee in the IT sector it is a great opportunity to get access to all
the knowledge presented at the conference, get hands-on with new technologies
and share the visions of some of the biggest names in the business. We tend to spend
more and more time behind our screens, teaching ourselves new tools, technologies
and reinventing the wheel. With Øredev there is a possibility to meet like-minded
people, share experiences and last but not least, to network. Adding new contacts on
your favorite social website is an important goal as any.
Besides the large amount of participants attending there is an increasing number
of exhibitors from all over the world. Be sure to sign up for next year, because the
conference will keep on growing, not only in the number of participants, but also
in importance. There is no better way to keep up to speed with the ever changing
market. Hopefully, the heat will be switched on in all seminar rooms by then.
Until next Øredev...

Stefan Li, Jakob Klamra, Mattias Severson

Originally published in JayView.