Sep 08 2009

Continuous Deployment with Hudson…

Since I was looking through the Hudson plug-in list this week, I decided to try a few more of them. We currently have Hudson continuously deploying a simple web application to a Tomcat instance. Since both Hudson and Tomcat are running on the same server, it was pretty simple to have Tomcat point to the WAR file generated during the build process. Tomcat notices the new WAR file and automatically redeploys the application. Pretty simple and pretty handy; this is about a 100 times easier and faster than dealing with our standard Weblogic deployment process!

So, how do you deploy your application if Hudson is running on a different machine than your Tomcat instance? Fortunately, Hudson provides a plug-in to solve this problem, simply named the Deploy Plug-in. It supports a variety of containers, taking advantage of the Cargo Framework. Can’t get much easier than this, just point to your WAR file and fill in the container information. That’s it! I tried it out today and it worked perfectly. This was a much cleaner approach than adding the logic to the build process.

Having the current code set continuously deployed is a great benefit all by itself. This helps ensure that your application is built correctly and is deployable; How many times have you forgot to add that new JAR file to the WAR, only to discover the failure several days later? Continual deployment also makes the application constantly available to the analysis and test teams. This allows everyone to see the current state of development and bounce through the application to see how it will ultimately work. This early exposure also gives developers a change to resolve issues much earlier in the development cycle. We can achieve more value by adding the integration or system testing to the process as well… Just think how much we could reduce our development and testing cycles with this level of testing?

I have been starting to read about Selenium on the Hudson mailing list and found this interesting blog by Ben Rometsch on “Easy Automated Testing with Hudson and Selenium“. I really liked this picture from the article (hopefully it will spark your interest too!) and truly believe this is what we should be working towards… Maybe this can be one of my next educational adventures!!!

https://www.beilers.com/wp-content/plugins/sociofluid/images/digg_48.png https://www.beilers.com/wp-content/plugins/sociofluid/images/reddit_48.png https://www.beilers.com/wp-content/plugins/sociofluid/images/dzone_48.png https://www.beilers.com/wp-content/plugins/sociofluid/images/stumbleupon_48.png https://www.beilers.com/wp-content/plugins/sociofluid/images/delicious_48.png https://www.beilers.com/wp-content/plugins/sociofluid/images/blinklist_48.png https://www.beilers.com/wp-content/plugins/sociofluid/images/blogmarks_48.png https://www.beilers.com/wp-content/plugins/sociofluid/images/google_48.png https://www.beilers.com/wp-content/plugins/sociofluid/images/facebook_48.png


Jul 07 2009

More Firefox Plug-ins – Useful Firebug Extensions

Category: Blogging,TestingPhil @ 7:41 pm

I found an interesting web that has all kinds of great information on website design. A highlighted a couple posts that I thought were very interesting: 10 Unusual Places to Get Design Inspiration and 10 Useful Firebug Extensions. You seriously should click on the design inspiration link, especially if you want to see how creative people can really be; check the beautiful web sites and unforgettable business cards. Truly amazing!

I also did not realize that people were building plug-ins to extend plug-ins! What a concept! I guess that is what makes Firefox such a powerful web browser, tool, platform; there are plug-ins to do about everything. I previously blogged about Firebug and YSlow, but I did not realize that Firebug was also a platform for other developer centric tools, such as HTML validation and code coverage. Someone was nice enough to create a Mozilla Collection for Web Debug Tools, it provides links to all of the referenced plug-ins. 

I recently found a plug-in that I wanted to share as well, called IE Tab. A couple of weeks ago, I was working on a web application and was validating the browser compatibility of our CSS; it was kind of painful switching back and forth between the IE and Firefox, especially since I preferred using Firefox. Fortunately, I discovered IE Tab, which is unfortunately not available on Linux! It simply embeds Internet Explorer in a Firefox tab to render the current page’s content. There will be a little browser icon in the lower right-hand corner of the window; it indicates which browser was used to render the page/tab. Just click on the icon to switch between the two rendering approaches. I think this is much better than having two switch between browsers! Maybe I’m just lazy! There is one small short coming using this approach, it can only use the version of Internet Explorer that you have installed on your computer. I happened to be using IE8 and our testers were using IE6. Needless to say, we had a couple of unexpected issues! Can you believe that IE6 is still being used? I think I would go crazy with out tabbed browsing!

https://www.beilers.com/wp-content/plugins/sociofluid/images/digg_48.png https://www.beilers.com/wp-content/plugins/sociofluid/images/reddit_48.png https://www.beilers.com/wp-content/plugins/sociofluid/images/dzone_48.png https://www.beilers.com/wp-content/plugins/sociofluid/images/stumbleupon_48.png https://www.beilers.com/wp-content/plugins/sociofluid/images/delicious_48.png https://www.beilers.com/wp-content/plugins/sociofluid/images/blinklist_48.png https://www.beilers.com/wp-content/plugins/sociofluid/images/blogmarks_48.png https://www.beilers.com/wp-content/plugins/sociofluid/images/google_48.png https://www.beilers.com/wp-content/plugins/sociofluid/images/facebook_48.png


Jun 23 2009

Doing more with jUnit: faster, cleaner unit testing

Category: Java,TestingPhil @ 9:20 pm

These are not really new features, but I bet most developers (like myself) have not given them the attention they deserve! Earlier this month, I read an interesting article on the Atlassian Developer Blog which peaked my jUnit interest. I remember reading about these features when jUnit 4.4 was released a couple of years ago (release notes), but I never took the time to try them out. JUnit included new abilities and concepts, such as Assumptions and Theories. To be real honest, the Assumptions and Theories sound really good in theory, but I’m not sure how practical they are in the real world! How can you argue with definition of a Theory… More flexible and expressive assertions, combined with the ability to state assumptions clearly, lead to a new kind of statement of intent.

First, I’m not sure how well Spring and Theories actually play together. They both need to have their own @RunWith annotation. Second, it is hard enough to get some developers to create a simple unit test! I will have to do some more pondering on Theories. Also, don’t get too carried away with the assumptions without doing some more reading; they have some rather unexpected behavior. Assumptions cause future assertions to pass, irregardless of the asserted value! Interesting?

The real power is in the “Matcher” functionality provided by Hamcrest, creating new capabilities (without writing additional code), a cleaner assertion syntax, creating more readable unit test code. Check out the multitude of convenince Matchers that are provided from Hamcrest. I focused on the power of the assertThat() method. The following code snippet demonstrates a couple of the matchers that I could have used a dozen times in the past and probably implemented my own nasty, non-reusable solution!

	@Test
	public void assertions() {

		final String colors = "color me crazy";
		final Collection<String> colorList = new ArrayList<String>();
		colorList.add("color");

		assertThat(colors, either(containsString("color")).or(containsString("colour")));

		assertThat(colorList, either(contains("color")).or(contains("colour")));

		assertThat("custom error message", colorList, //
				not(either(contains("red")).or(contains("green"))));

		assumeThat(colorList, contains("red"));
		fail("jUnit Still successful!! Does not fail!");
	}

Random Thoughts…

  • jUnit 4.6 was recently released (release notes). I did not see anything exciting in new new release, other that some new integration with JUnit Max.
  • As cool as JUnit Max sounds, it is now dead to me! The subscription fee has jumped to $10 per month… That is more than my XM Radio subscription!!! If continuous testing is really that cool, hopefully, other smart people are working on even better, open-source alternatives!
  • The Spring 2.x framework integration was broken with jUnit 4.5 and required version 4.4. The new 3.x version of Spring, still in beta, works with both 4.5 and 4.6. It actually no longer works with 4.4!
https://www.beilers.com/wp-content/plugins/sociofluid/images/digg_48.png https://www.beilers.com/wp-content/plugins/sociofluid/images/reddit_48.png https://www.beilers.com/wp-content/plugins/sociofluid/images/dzone_48.png https://www.beilers.com/wp-content/plugins/sociofluid/images/stumbleupon_48.png https://www.beilers.com/wp-content/plugins/sociofluid/images/delicious_48.png https://www.beilers.com/wp-content/plugins/sociofluid/images/blinklist_48.png https://www.beilers.com/wp-content/plugins/sociofluid/images/blogmarks_48.png https://www.beilers.com/wp-content/plugins/sociofluid/images/google_48.png https://www.beilers.com/wp-content/plugins/sociofluid/images/facebook_48.png


Jun 10 2009

Hudson Continuous Integration and Eclipse Update Sites

I was looking for a development build of the IvyDE plug-in for Eclipse tonight and I stumbled across the Apache Hudson server. You have to check this out. Pretty cool, Hudson running over 150 jobs!  Their build farm consist of both Solaris and Ubuntu servers. What I found most interesting was how they used Hudson for creating an Eclipse update site. I subscribe to the Hudson mailing list, summarized here, to follow what is going on with the project. People seem to use Hudson for a variety of different purposes, such as a cross platform testing tool and even as a deployment tool. I have only been able to get people interested in Hudson as a “Cruise Control” replacement…. but at least it is a good start!

This site also demonstrates how multiple projects can be linked together, triggering builds of dependent downstream projects.  I’m not exactly sure how these jobs were assembled, but at a high-level, Ivy and IvyDE each have its own build loop (job). Each job is responsible for creating build artifacts. After a successful build of either job, a third job is triggered which creates/updates and Eclipse update site.  Pretty slick. (As any FYI, the dev plug-in looks better, new presentation and several new new options)

Another small plug for Continuous Integration. We recently set up something kind of cool (trivial, but cool)! As we continue trying to convince the powers that be, to move away from Weblogic towards Tomcat (or even JBoss), we found a really nice little feature. Since Tomcat and JBoss can hot deploy a new version of the WAR file, just by noticing a difference on the file system, combined with the fact that we can spin up a Tomcat instance in about 2 minutes, we actually created an auto deployment mechanism.  Our Weblogic environment seems so cumbersome in comparison…. We could have built the WAR and deployed in in our build loop, but that would have minimally added another 25 minutes to the loop (let’s just say we have an interesting deployment process). With Tomcat, we did a one time deployment to the location of the WAR file inside the Hudson workspace. Now, with each series of check-ins, we build the WAR as normal and Tomcat instantly deploys it, in seconds! If we were a little more sophisticated, we would write some jUnits to bang against it, making sure we did not break anything or create any new dependencies.  Maybe I will throw that in during my next project!!! I know this integration was possible before (with Weblogic), but no way as simple!  Even better Continuous Integration… on my last project I had Ant spin up an embedded Jetty web server, ran my jUnits against the Clover instrumented code, and finally had Ant shut down Jetty…. Pretty slick, from a code coverage collection perspective…

https://www.beilers.com/wp-content/plugins/sociofluid/images/digg_48.png https://www.beilers.com/wp-content/plugins/sociofluid/images/reddit_48.png https://www.beilers.com/wp-content/plugins/sociofluid/images/dzone_48.png https://www.beilers.com/wp-content/plugins/sociofluid/images/stumbleupon_48.png https://www.beilers.com/wp-content/plugins/sociofluid/images/delicious_48.png https://www.beilers.com/wp-content/plugins/sociofluid/images/blinklist_48.png https://www.beilers.com/wp-content/plugins/sociofluid/images/blogmarks_48.png https://www.beilers.com/wp-content/plugins/sociofluid/images/google_48.png https://www.beilers.com/wp-content/plugins/sociofluid/images/facebook_48.png


May 19 2009

How to customize your jUnit Behavior and Interaction

Category: Java,Misc,Testing,UbuntuPhil @ 8:17 pm

I have tried to walk through the jUnit source code a couple of times, trying to figure out how to implement my own behavior; only to give up in frustration (no I did not read the documentation, real developers don’t do that, they Google!) Why would I want to implement my own behavior? Well, it always seems to center around integrating with Spring. I usually want/need to do control the way the context is being created or do something immediately before the context is loaded or as the context is loading; something that might not be possible not possible using a @BeforeClass annotation.

This problem was actually related to my previous blog on Implementing Custom Scopes in Spring. Because I implemented some beans using the session scope, I kind of created a catch-22 scenario;  I have tried to capture the problem in bullet form:

  • Each jUnit test needs the ability to specify the specific test user (role, user info, etc.) that is relevant for that individual test
  • The test user profiles are configured and controlled by a Spring managed bean
  • All beans are lazy-init = true and injected into the unit test using the @Resource annotation
  • The session scope beans need to have the SecurityContextHolder configured with the appropriate principal (test user), before they are created
  • So, the problem is: How do you specify the test user, before the session scope beans are created and injected into the unit test class?

In a normal execution environment, using the Spring Security filters and a Servlet, the SecurityContextHolder would have been assigned using the authenticated principal, before creating any Spring dependencies. Because I created my own custom scopes for unit testing, the SecurityContextHolder was null and the session scope beans constructor was failing an assertion (principal != null). I could have easily fixed this by adding a pre-authenticated user to the SecurityContextHolder, using some static method approach,. However, because my mechanism for handling test users was itself a Spring bean, I had no possible way of specifying before the beans were injected into my unit test.

When jUnit 4.0 was released, it added several new constructs that make some very elegant solutions. I don’t think most developer’s ever look beyond the base jUnit functionality; fortunately it seems to solve 99% of the typical test scenarios. The new constructs are actually specified via annotations, they are the @RunWith and @TestExecutionListeners. My example code, can probably be made a little cleaner, but my main goal was to get the unit tests working. Because you don’t directly create any of these objects, you have to be aware of the timing; implement your customizations at  the correct point in the lifecycle. Another interesting problem, is that you don’t actually create the Spring Context, but you can interact with it via listeners.

First, we need a class which extends DependencyInjectionTestExecutionListener. This base class is required when using Spring and provides several override-able methods. I needed to configure the SecurityContextHolder, before any beans were injected into the unit test; I could accomplish this by utilizing the injectDependencies method. To support my testing needs, I added two (2) properties to the sub-class (this could have been cleaner); one to specify a user from a “user provider” factory, and a simpler one that used the user id of the person running the test. As you can see from the code, before an beans are injected into the unit test, I have access to the Spring context. This allows me to request the “user provider” factory and then request a specific test user. At this point, I can now assign the user to the SecurityContextHolder; all before any of the session scope beans are created.

public class AuthorizedTestExecutionListener extends DependencyInjectionTestExecutionListener {

    private TestUserAuthorization defaultAuthorization;
    private String                junitAuthorization;

    public void setJunitAuthorization(final String junitAuthorization) {
       this.junitAuthorization = junitAuthorization;
    }

    public void setDefaultAuthorization(final TestUserAuthorizationdefaultAuthorization) {
       this.defaultAuthorization = defaultAuthorization;
    }

    @Override
    @SuppressWarnings("PMD.SignatureDeclareThrowsException")
    protected voidinjectDependencies(final TestContext testContext) throws Exception {
       if (StringUtils.isNotBlank(junitAuthorization)) {
           final Authentication login = new UnitTestAuthenticationToken(this.getClass().getSimpleName());
           SecurityContextHolder.getContext().setAuthentication(login);
       }
       else if (defaultAuthorization != null) {
           finalTestUserModuleManager manager = (TestUserModuleManager) testContext.getApplicationContext()
                    .getBean(defaultAuthorization.testUserManager());
           final SecureUserInterface user = manager.find(defaultAuthorization.principal());
           final Authentication login = new UnitTestAuthenticationToken(user);
            SecurityContextHolder.getContext().setAuthentication(login);
        }

       super.injectDependencies(testContext);
    }
}

Next, we need to extend SpringJUnit4ClassRunner. This class is responsible for for creating the Spring test context and  DI listener class.  By over-ridding the  createTestContextManager, you have the opportunity to configure the test execution listeners.  I  also created two custom annotations, TestUserAuthentication and  JUnitAuthentication.  Using either one of these annotations, I could provide run-time meta-data  to my  custom AuthorizedSpringjUnit4ClassRunner; the meta data was then used to configure my custom  AuthorizedTestExecutionListner.

public class AuthorizedSpringjUnit4ClassRunner extends SpringJUnit4ClassRunner {

    public AuthorizedSpringjUnit4ClassRunner(final Class<?> clazz) throws InitializationError {
       super(clazz);
    }

    @Override
    @SuppressWarnings("PMD.ConfusingTernary")

    protected TestContextManager createTestContextManager(final Class<?> clazz) {

       final TestUserAuthorization defaultUser = clazz.getAnnotation(TestUserAuthorization.class);
       final JUnitAuthorization jUnitUser = clazz.getAnnotation(JUnitAuthorization.class);

       final TestContextManager context = super.createTestContextManager(clazz);

       for (final TestExecutionListener l : context.getTestExecutionListeners()) {
           if(AuthorizedTestExecutionListener.class.isAssignableFrom(l.getClass())) {
               if (defaultUser !=null) {
                    ((AuthorizedTestExecutionListener) l).setDefaultAuthorization(defaultUser);
                }
               else if (jUnitUser != null) {
                    ((AuthorizedTestExecutionListener) l).setJunitAuthorization(clazz.getSimpleName());
                }
            }
        }
       return context;
    }
}

Once you understand what all of the pieces do, they are super easy to customize to provide enhanced behavior. I think my solution provided a very clean, elegant solution for providing test specific user profiles, on a test by test basis.

@RunWith(AuthorizedSpringjUnit4ClassRunner.class)
@TestExecutionListeners(AuthorizedTestExecutionListener.class)
@ContextConfiguration(locations = {//
"/com/beilers/resources/spring/contexts/jUnitContext.xml" //
})

public class UnitTestHelper {
...
}
https://www.beilers.com/wp-content/plugins/sociofluid/images/digg_48.png https://www.beilers.com/wp-content/plugins/sociofluid/images/reddit_48.png https://www.beilers.com/wp-content/plugins/sociofluid/images/dzone_48.png https://www.beilers.com/wp-content/plugins/sociofluid/images/stumbleupon_48.png https://www.beilers.com/wp-content/plugins/sociofluid/images/delicious_48.png https://www.beilers.com/wp-content/plugins/sociofluid/images/blinklist_48.png https://www.beilers.com/wp-content/plugins/sociofluid/images/blogmarks_48.png https://www.beilers.com/wp-content/plugins/sociofluid/images/google_48.png https://www.beilers.com/wp-content/plugins/sociofluid/images/facebook_48.png


May 17 2009

Unit Testing Custom Spring Scopes

Category: Java,TestingPhil @ 6:45 pm

I recently worked on a JSF-based application that was integrated with Spring, both the Core Framework as well as the Spring Security Framework. I certainly don’t have it all mastered, but the experience has given me multiple topics to blog about! We decided to let Spring manage all of the beans, rather than making JSF manage some of the beans and Spring manager the rest. I liked the consistency and thought it would make unit testing easier. Spring provides two basic scopes, singleton and prototype. When you add Spring Security into the mix, you get two additional scopes, one for session and another for request.

This should have been no big deal. To my surprise, when I wrote my first unit test, I discovered the session and request scopes were not supported; the bean factory threw an unsupported scope exception when I asked for the bean. Googling did not lead to any exact answer, but I found lots of examples; many developers seem to implement a thread scope. I simplified one of the many implementations I found, as I only need to support unit testing.

The first step is to build your own class that implements the Spring Scope interface. I created a generic class, such that I could use it for any custom scope.

public class CustomScopeHandler implements Scope {

     private final Map<String, Object> hBeans = new HashMap<String, Object>();

     public Object get(final String name, final ObjectFactory factory) {
        Object result = null;

        if (hBeans.containsKey(name)) {
            result = hBeans.get(name);
        }
        else {
            result = factory.getObject();
            hBeans.put(name, result);
        }

        return result;
    }

    public Object remove(final String name) {
        Object result = null;

        if (hBeans.containsKey(name)) {
            result = hBeans.get(name);
            hBeans.remove(name);
        }

        return result;
    }

    public String getConversationId() {
        Assert.state(true, “Needs to be implmented – ConversationId”);
        return “N/A”;
    }

    @SuppressWarnings(“PMD.DoNotUseThreads”)
   public void registerDestructionCallback(final String name, final Runnable callback) {
        Assert.state(true, “Needs to be implmented – DestructionCallback”);
    }
}

The next step is to add your custom scopes to the IoC container. Using the Spring CustomScoptConfigurer class, you can easily add as many scopes as you like. Pretty simple! Now you can execute your unit tests as you would have initially expected. One thing to be aware of, this implementation treats beans as if they are singletons. You could easily eliminate the Map and return back new instances on each invocation. It all depends on your specific needs, mine were pretty simple.

      <bean class=”org.springframework.beans.factory.config.CustomScopeConfigurer”>
            <property name=”scopes”>
                  <map>
                        <entry key=”request”>
                              <bean class=”test.scope.CustomScopeHandler” />
                        </entry>
                        <entry key=”session”>
                              <bean class=”test.scope.CustomScopeHandler” />
                        </entry>
                  </map>
            </property>
      </bean> 

https://www.beilers.com/wp-content/plugins/sociofluid/images/digg_48.png https://www.beilers.com/wp-content/plugins/sociofluid/images/reddit_48.png https://www.beilers.com/wp-content/plugins/sociofluid/images/dzone_48.png https://www.beilers.com/wp-content/plugins/sociofluid/images/stumbleupon_48.png https://www.beilers.com/wp-content/plugins/sociofluid/images/delicious_48.png https://www.beilers.com/wp-content/plugins/sociofluid/images/blinklist_48.png https://www.beilers.com/wp-content/plugins/sociofluid/images/blogmarks_48.png https://www.beilers.com/wp-content/plugins/sociofluid/images/google_48.png https://www.beilers.com/wp-content/plugins/sociofluid/images/facebook_48.png


Apr 23 2009

Moving from Continuous Integration to Continuous Testing…

Category: Java,TestingPhil @ 1:01 am

I have been following Kent Beck on Twitter for some time, keeping an eye on his jUnit Max product. I think it is a very cool idea, especially with the Eclipse integration. If you have a well written jUnit suite, this could be pretty slick. I only wish Kent would kill the subscription idea; I can’t really blame him for wanting to make money, he just won’t be getting any from me! It is a bummer the tool is not free. It is hard enough to get some developers to build unit tests, now I’m going to charge them a subscription fee to execute the tests… Not happening!

Here was a short little post on the concept. Give it a read and share your thoughts…

https://www.beilers.com/wp-content/plugins/sociofluid/images/digg_48.png https://www.beilers.com/wp-content/plugins/sociofluid/images/reddit_48.png https://www.beilers.com/wp-content/plugins/sociofluid/images/dzone_48.png https://www.beilers.com/wp-content/plugins/sociofluid/images/stumbleupon_48.png https://www.beilers.com/wp-content/plugins/sociofluid/images/delicious_48.png https://www.beilers.com/wp-content/plugins/sociofluid/images/blinklist_48.png https://www.beilers.com/wp-content/plugins/sociofluid/images/blogmarks_48.png https://www.beilers.com/wp-content/plugins/sociofluid/images/google_48.png https://www.beilers.com/wp-content/plugins/sociofluid/images/facebook_48.png


Apr 22 2009

Validating and Managing Argument Dependencies with Args4J

Category: Java,TestingPhil @ 7:17 pm

I recently reviewed some Java code that was designed to process a set of arguments; my first thought… there has to be a better way! I did a quick Google search and found multiple command line processor implementations. My favorite seems to be the Args4J implementation. I like the simple Java Bean approach, taking advantage of Java 1.5 annotations, enumerations, and generics. The best part is the auto-magic type conversion from string arguments to bean properties. It feels a little like Apache BeanUtils, but the annotation processing makes it more flexible.  A pretty slick implementation, but with a couple of small tweaks, would have been even better.

The Args4J implementation provides an ample collection of option handlers to support automatic type conversion of the basic Java types. Option handlers are provided for the all of the numeric types, URLs, Files, bounded lists (enumerated values), as well as unbounded lists. The implementation is easily extended; custom option handlers can be added to support your own object types or specific input formats, such as dates.

Overall, Args4J is very well done; I would have liked to see a little more support in the following areas:

  1. Args4J provides no default support for handling Java Date Types. I created a simple abstract option handler to support any data format.  A concrete class is required for each desired format; but the subclass only needs to provide the requested date string format. An abstract date handler class might be a nice addition to Args4J, even though it was very simple.
  2. Args4J does not provide any type of argument validation, beyond basic type conversion. In my AbstractDateHandler class, I implemented a validate(<T> value) method. The validate method is invoked before the date instance  is “set” on the bean.  This implementation allowed me to ensure the specified date was before today’s date.  This was really pretty clean; if the specified date was in the future, the option handler threw a CmdLineException containing the validation error in the message. This exception was handled up the call stack, just like any other type conversion issue, no special coding required.
    • I can see this being very useful for numeric types as well. Maybe only positive integers are valid for as a specific parameter. The current Args4J implementation provides no way to seamlessly provide this type of validation via the Option Handlers (without cloning an the existing handler).
    • This type of validation can be implemented in the Java bean, but the annotation must be specified on the setter, rather than the property.  Some developers might actually prefer the validation logic it in the bean. Personally, I would rather see this logic managed by the option handler.
  3. The biggest hole in the implementation is the management of argument dependencies. For example, it would be nice to validate if the specified start date parameter is before the end date parameter, or if the print parameter is specified, the filename parameter is not allowed. This type of validation can be implemented in the bean, but would be invoked outside of the argument processing flow. You will have to mange exception logic in two places, once for the “type conversions” and another for the intra-argument dependencies.
    • There are some flaws in my theory, but I thought it would be better if the option handlers had some knowledge of their own dependencies. My theory works well for required options, but not so well for optional ones.
    • I created a custom CmdLineProcess class, which was hidden by suggestion #4 below. This class owned a dependency manager instance which made the previously processed command line values available to the current option handler.
    • An ArgumentsDependency class was accessible during the validation process. The handler could now ask the dependency manager for values that were processed by other handlers. In this example, the EndDateHandler is asking for the dependency manager for the value parsed by the StartDateHandler.
    • I know this is not perfect, but I really like the way the validation is implemented in a consistent manner, making it possible to handle all exceptions the exact same way.
  4. The implementation also provides a Starter class, which eliminates the need for the developer to write a main() method. It is an interesting idea, but I need to give this style a little more thought! I like having my options class independent of the execution class. The Starter approach merges the options and driver (main) logic into one single class.  I would have preferred to see an argument processor class, with a method like: public T parseArgs(final String[] args, final Class<T> clazz). The argument processor would catch all of the exceptions and output the validation errors and usage information; the caller would need to do no extra processing or validation.

I hope this gives a little more insight into how Args4J is actually implemented and one possible method for extending it. Maybe someone has already handled these problems in a more elegant manner, but I did not to change any of the Args4J source code. That restriction did not give me a lot of flexibility to implement my enhancements!  Overall, Args4J is a simple and elegant solution for sometimes messy problem.

https://www.beilers.com/wp-content/plugins/sociofluid/images/digg_48.png https://www.beilers.com/wp-content/plugins/sociofluid/images/reddit_48.png https://www.beilers.com/wp-content/plugins/sociofluid/images/dzone_48.png https://www.beilers.com/wp-content/plugins/sociofluid/images/stumbleupon_48.png https://www.beilers.com/wp-content/plugins/sociofluid/images/delicious_48.png https://www.beilers.com/wp-content/plugins/sociofluid/images/blinklist_48.png https://www.beilers.com/wp-content/plugins/sociofluid/images/blogmarks_48.png https://www.beilers.com/wp-content/plugins/sociofluid/images/google_48.png https://www.beilers.com/wp-content/plugins/sociofluid/images/facebook_48.png


Feb 10 2009

Hudson Overview

Category: Continuous Integration,TestingPhil @ 10:48 pm

I was playing with Hudson today in what I would call a non-standard, maybe non-friendly Linux box. The first time I setup Hudson, Java and Ant were installed in the standard locations; once I configured my projects, Hudson just went to work. On the non-standard box, nothing was installed in the expected locations, fortunately this was no big deal. The Hudson configuration options are simple and numerous.  The system level configuration page has options to configure the JDK, Ant, Maven, Shell, and email settings; which are all specific to the machine that Hudson is installed on.  At first, I thought this might be limiting, as very few projects use the same version of these tools. Luckily, the configuration page has the ability to specify the JAVA_HOME and ANT_HOME for multiple versions of each tool.  This allows each project to specify which version of the tool they want to use in their build process, pretty simple.

One of the more interesting system level configurations addresses Hudson’s security. There are five different security options, from no security to per-project security.  For authentication, I configured Hudson to use an LDAP server. This took a little trial and error, as this feature does not seem to be well documented. Fortunately, it only took a couple of attempts and the login screen started working. I chose to implement project-based security; this allowed me to delegate the responsibility of each user’s role to the project’s owner. This seemed like a good approach for limiting the amount of work required by the Hudson administrator.  There could be simpler configurations, especially if you wanted to manage fewer people, but this approach gave me the finest grain control over each person’s ability… which might actally be overkill is practice. I would really need to see this working on a real  project before I would be able to suggest the best security option, but it would seem to work in multiple environments.

The final step is to create and configure an individual project, which is also very straight forward. First, you pick the version control system and enter the repository and access information. Next, select the Ant-based project option and type in the Ant target name that is responsible for the continuous integration. There are multiple options you can configure here as well, but that is all I needed to start the process. Because Java and Ant were not installed in their normal locations, I selected the appropriate versions, as configured in the system level. That was it. I hit the build button and off it went. Hudson provides all kinds of visual feedback on the dashboard, letting you know exactly what is building, and even predicts how long until the current build finishes. One of the more interesting features is the ability to watch the build from within the dashboard (web page).  Hudson uses AJAX to capture the log file of the running Ant process and shows a live update to the user. Pretty cool, it is no different than running Ant in a local shell!

This tool seems significantly simpler to get working than Cruise Control. I really like that fact that every project can be configured to match its own requirements.  Some projects might want to use Checkstyle and PMD, another project might want to use FindBugs; not a problem. Once the plug-ins are installed by the administrator, Hudson makes them available to each project and automatically published the collected results. Because of this project centric view, it is even easier to integrate with multiple version control systems, each project simply chooses the appropriate back-end.

I did want to mention that Hudson seems to be a tool that extends beyond the typical developer requirements. As I mentioned in a previous post, QA groups can also use Hudson for activities other than continuous integration.  One interesting feature is Hudson’s ability to monitor external jobs. This allows you to record the execution of a process run outside Hudson, even on a remote machine. It was designed so that you can use Hudson as a dashboard of your existing automation system. Hudson even have multi-server scalability built-in. This allows the environment to be configured with helper machines to distribute the processing load, taking advantage of the remote resources, while centrally managing and monitoring the process.

Hudson appears to have been pretty well thought out. Hopefully someday soon, I can use it for real!

https://www.beilers.com/wp-content/plugins/sociofluid/images/digg_48.png https://www.beilers.com/wp-content/plugins/sociofluid/images/reddit_48.png https://www.beilers.com/wp-content/plugins/sociofluid/images/dzone_48.png https://www.beilers.com/wp-content/plugins/sociofluid/images/stumbleupon_48.png https://www.beilers.com/wp-content/plugins/sociofluid/images/delicious_48.png https://www.beilers.com/wp-content/plugins/sociofluid/images/blinklist_48.png https://www.beilers.com/wp-content/plugins/sociofluid/images/blogmarks_48.png https://www.beilers.com/wp-content/plugins/sociofluid/images/google_48.png https://www.beilers.com/wp-content/plugins/sociofluid/images/facebook_48.png


Feb 03 2009

Unit Testing and building a Ford Focus…

Category: TestingPhil @ 10:35 pm

I was chatting with a friend today, and he told me a story that I could not believe. More interesting, was the fact that his story sounded exactly like my last post on Software Quality. His team was not on the same page, they each had different development philosophies and others used the existing environment to squash his proposal. So, what was his crazy idea? He proposed that the project use jUnit during the development process, and to add a line item to the project plan to include unit testing. He thought if unit testing was part of the project plan, the team would have a little more incentive to participate.

To his surprise and my dismay, the project manager said, “We are not building a Mercedes, we are building a Ford Focus, and doing unit testing is essentially unnecessary”. Oh my gosh, I about blew a gasket! I have been doing test driven development for so long, I would not even know how to write code without a unit test! What am am missing? Why wouldn’t a team want to create unit tests? How do they validate what they are building? Do they just use Loggers or print lines statements to generate output and then visually inspect the results?

This is one question that I have never been able to answer; why would a developer not want to create a structured unit test? Why do they prefer to add a “main” method to execute the code, rather than simply creating a jUnit test? I will not go into the benefits of using a continuous integration tool at this time, but just having a jUnit test that other developers could execute must be of some value. Right? Why would I want to continually inspect the output results of the class execution, when I could use assertions to actually validate the results of each test? The power, flexibility, speed, and maintenance of jUnit is not even comparable to value provided by a simple main method.

I personally believe that creating a unit test adds absolutely nothing to the overall cost of development. After all, the developer has to create something to validate the code, right? I have never seen a developer just sits down, write the code, and send it off to production. If code has to be executed to be validated, why not use jUnit? Throw in a tool like Eclipse, NetBeans, or IntelliJ, and it makes unit testing almost trivial. All the developer needs to do is click on a button and tool executes the unit test; these tools even have fancy windows to quickly show the result of each test, indicating success or failure.

There could be some potential downstream cost to supporting a unit test suite, but this cost has to be the same or less than than maintaining all of those of main methods. I also believe that the cost of supporting the unit test suite is offset by the total value provided by the suite. This value will be realized as the system evolves, allowing the team to refactor code, providing a validation framework for their changes.

Help me out here… Am I wasting my time building unit tests or have the other developers just not seen the light? Actually, I don’t think I am wasting my time, nor will I quit writing unit tests any time soon!

https://www.beilers.com/wp-content/plugins/sociofluid/images/digg_48.png https://www.beilers.com/wp-content/plugins/sociofluid/images/reddit_48.png https://www.beilers.com/wp-content/plugins/sociofluid/images/dzone_48.png https://www.beilers.com/wp-content/plugins/sociofluid/images/stumbleupon_48.png https://www.beilers.com/wp-content/plugins/sociofluid/images/delicious_48.png https://www.beilers.com/wp-content/plugins/sociofluid/images/blinklist_48.png https://www.beilers.com/wp-content/plugins/sociofluid/images/blogmarks_48.png https://www.beilers.com/wp-content/plugins/sociofluid/images/google_48.png https://www.beilers.com/wp-content/plugins/sociofluid/images/facebook_48.png


« Previous PageNext Page »