Verify the World

Image via Wikipedia

Image via Wikipedia

My company is moving our build process from an Ant script to Maven.  This is going to make everything so much easier!  Whereas our Ant script required a bunch of projects to be checked out, configured just so, and deployed to attachable JARs, now all these projects can be stored in our repository manager and just be referred to by the parent POM as dependencies!

The challenge herein is to adapt my automation framework to use Maven instead of Ant.  This is essential for developer adoption, and also heightens my awareness of a tool that we intend to use to ensure the quality of our product.  Either of these are noble goals, but taken together, are too much impetus to ignore.

This transition requires quite a shift in perspective, and unfortunately, some additional planning I had avoided in true hacker style.  See, I was using Ant not only to build my application, but also to execute it (via the TestNG Ant task) and to produce test reports (via ReportNG).  I chose to go this route because: a) I was lazy, and b) I was inexperienced in software development.

Now, Maven may, with some tooling, allow me to preserve this approach.  But at what cost?  My super-custom build structure would undo much of the benefit of Maven; that of  ”convention-over-configuration“.  If my process is so specialized as to require a new developer on the project, or a new user of the artifacts, to read and understand the build process, then Maven will have cost me much and bought me little.

Rather than to port my build process to Maven, I’ll need to re-evaluate the structure of my application as a whole.  I’m considering splitting the project into the core framework and the application-specific implementation.  Instead of a task in the build tool, I’ll write an entry point class that kicks off the TestNG tests with my desired configuration.  Wrap the whole shebang into a JAR and upload it to the local Maven repository manager, and I’ve got a dependency that can be used during the integration-test phase.  Voila!

Java Power Tools

This book was an impulse purchase.  About a year ago, I was wandering through my local book mega-store with my wife, looking for guides on how to raise a puppy.  As I tend to do, I gravitated toward the technical section of the bookstore.  I had taken a few classes on Java at my local community college, and wanted to eventually make a living at it, so I scanned the available books on Java.  That was when Java Power Tools caught my eye.  This book is certainly focused on Java, but it is not a programming manual, not a language specification, not an exam study guide.  It is a reference that leads the reader through the extensive world of open-source tools written to make Java software development easier and more fun.

Any organization worth its salt uses at least some of the tools described herein, and many of the larger-scale enterprises will use quite a few, often together in interlocking ways.  If you’re serious about Java development, you need to know how to use the available build tools, unit testing frameworks, issue trackers, source control management, continuous integration, code coverage, and profilers.  This book answers the vital questions of:  ”what is it?”, “where can I find it?”, “how do I use it?”, and “why do I need it?”.

As a young tester peeking my head out of the black box for the first time, I found answers to all the questions that I had stored away in my head about these mysterious terms “Ant”, “CruiseControl“, “JUnit“, and “CVS”.  Most importantly, I had finally internalized that there is far more to Java software development than just the programming language chosen.  In order to develop and release quality software, an organization must rely upon many tools (power tools) to work with the greatest possible efficiency and focus.  In the past year, I’ve used many of these tools myself, either to improve my organization’s build and release process, or to power my own Java-based automation framework.  I don’t know that I could’ve progressed with as much confidence and persistence had it not been for this book.  I’d recommend it to any blossoming Java developer, quality assurance professional in a Java shop, or project manager looking to improve the release process.

Hello world, with <angular/>!