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!

I really wanted to attend GTAC this year. For reasons not thoroughly explained, my application for attendance was denied. Am I bitter? Not really. I’m not at all one of the big minds in test automation. If anything, I’m a fly on the wall, gathering and applying as much from the stream of information that I can. I’ve been doing this for less than a year, all told. While I’m proud to the point of bursting for what I have accomplished in that time, I know better than to consider myself a prodigy or among the elite. That doesn’t mean I wouldn’t like to get there, and this blog is a part of that process.

So, now that GTAC is behind us, and the speakers have published their slides, I’ve taken the time to read through them, to see what new information or techniques I can apply to my own work. I’ll link to each and post a brief review, as applies to web test automation using Selenium & TestNG.

More »

Much more empirical than my own.

Give it a read here!

In the world of unit testing frameworks for Java, there are really only two that truly stand out: JUnit and TestNG.

While JUnit is the de-facto standard, and rightly so (it’s been imitated in every language from C# to Perl).  JUnit provides a comprehensive assertion library, integrated support for build management tools like Ant and Maven, as well as just about every continuous integration tool worth mentioning, and even IDE support for the most popular Java IDEs.  However, there are a few areas where JUnit just doesn’t meet every developer’s needs.

Enter TestNG.  TestNG (the “NG” stands for “Next Generation”) was developed as a replacement for JUnit 3.x, which, at the time was found to be very restrictive.  JUnit test classes had to extend org.junit.TestCase, setUp() and tearDown() methods had to be named just that and contain empty-argument signatures, to name just a few of the limitations.  TestNG, on the other hand, used the whiz-bang new J2SE 5.0 Annotations paradigm to bless any method you please as a unit test, set-up method, or otherwise.  JUnit was quick to follow suit in 4.x.  What JUnit still can’t buy you these days is parallel execution support.  Much of the value of unit tests is that they are fast.  However, in a large application, you could have thousands of unit tests, and the amount of time spent running each in turn could negate the benefit of having them in the first place.

Re-enter TestNG in billowing cape and tights.  With TestNG, all your unit tests can run in parallel using a configurable thread pool, with fail triggers that watch execution time or run the same test multiple times in a row, reporting a failure only if the test fails more than a certain percentage of executions.

Another really cool feature of TestNG is the “data provider” method.  Unit tests are great, because they can exercise a method in your class-under-test and expect a particular result.  However, that method would probably produce a deterministic result for any number of different data.  Using a data provider, you can call your test method over and over again with different arguments, exercising your method-under-test with a wide range of inputs!  Just change your test method signature to take in whatever input values you’d like to apply to your method-under-test.  Then, add the dataProvider=”someString” attribute to your @Test annotation.  Now, create a new method with the @DataProvider annotation and a matching name=”someString” attribute.  A data provider method takes no arguments and returns either an Object[][] or an Iterator<Object[]>.  (I find the latter to be more useful, as it conveniently allows you to use a Collection<Object[]> within the method, and then call iterator() in the return statement.) The first dimension of the array is the list of argument sets.  The second dimension of the array the actual list of arguments.

You’re all set!  When your test method is executed, it will be run once for each entry into the data provider’s return object!  Now that’s some good exercise for your method-under-test!

Like what you’re reading, but already using JUnit 3 or 4?  The official distribution of TestNG comes with a conversion mechanism that will run through your code and update all your JUnit tests to TestNG tests!  How cool is that??

There are more cool features of TestNG than I can get into, here.  I’d recommend reading the official page thoroughly.  For my purposes, I give TestNG two thumbs up!

Reblog this post [with Zemanta]