Verify the World

OK, “complete” in the sense that it is operational. One thing I’ve learned in my efforts is that, once you go Maven, you go a lot of other directions, as well.

For instance, I elected not only to let Maven build my project, but also to modularize it. My functional test automation framework is now split into four modules:

1. Core
   • Page definition file interpreters
   • Interfaces and abstract classes to represent pages, business logic classes
   • Abstract data validation classes
   • UI object models
   • All the logic and models that make the framework go.
2. Test
   • Page layout definitions
   • Page action definitions
   • Test manifests
   • Data-driven test classes (Data providers)
   • Application-level model classes
   • Concrete data validation classes
   • Concrete page interaction classes
   • Application-level configuration
   • Functional tests
3. Report
   • Test failure screenshot logic
   • Test result recording
     • HTML reports
     • Database records
4. Tools
   • Server access scripts
   • Supporting utilities

That’s the conceptual split between these modules.  In practice, there’s still a lot of work to make each as independent as I’d like.

Maven is already building and modularizing my project.  Why not let it help me to integrate new dependencies, as well?  Since converting to Maven, I’ve added a connection pool manager called BoneCP.  I didn’t have to download a JAR (and all the JARs that JAR depends on).  I just added the dependency to the POM file, and Maven did the rest automatically, behind the scenes.  Now, when I build my project, that dependency is automatically downloaded (if necessary) and linked into my classpath.  I did the same with Apache Commons DbUtils.  Just a quick reference in the POM in the module that requires these dependencies, and it’s done.  When I release a version of my framework to my company’s repository manager (Artifactory), those dependencies will be automatically acquired and linked by any other project that depends on mine.

I have a few more near-term features and goals for which this transition to Maven is going to be very helpful, if not essential:

1. Automate the execution of my functional tests whenever a build of our web application is done.
2. Extract any configuration of my application out of custom XML files and Java code, and into Maven profiles.
3. Replace BoneCP with a more mature (read: more complex) connection pool manager.
4. Incorporate object/relational mapping into the data validation code.

I’ll be posting on the more interesting of these goals as they become reality.