Archive for March, 2009

Super simple method to create a boolean decision table

Posted in software development, testing on March 27th, 2009 by Joerg – 3 Comments

Today one of our test engineers, Manfred, presented about systematic identification of test values. One of the topics were decision tables. I was fascinated how easy he created tables with all possible combinations. Here is how:

  1. Write the conditions in seperate rows.
  2. Condition A
    Condition B
    Condition C
    
  3. Now make 2^n columns where n is the number of conditions.
  4. Condition A |   |   |   |   |   |   |   |   |
    Condition B |   |   |   |   |   |   |   |   |
    Condition C |   |   |   |   |   |   |   |   |
    
  5. Start at the bottom condition and write alternating Y and N.
  6. Condition A |   |   |   |   |   |   |   |   |
    Condition B |   |   |   |   |   |   |   |   |
    Condition C | Y | N | Y | N | Y | N | Y | N |
    
  7. Fill the next row with alternating Y Y N N …
  8. Condition A |   |   |   |   |   |   |   |   |
    Condition B | Y | Y | N | N | Y | Y | N | N |
    Condition C | Y | N | Y | N | Y | N | Y | N |
    
  9. Each row you double the number of consecutive Ys and Ns.
  10. Condition A | Y | Y | Y | Y | N | N | N | N |
    Condition B | Y | Y | N | N | Y | Y | N | N |
    Condition C | Y | N | Y | N | Y | N | Y | N |
    
  11. Do so until all rows are filled.
  12. Now you can add your decisions to the table.
  13. Condition A | Y | Y | Y | Y | N | N | N | N |
    Condition B | Y | Y | N | N | Y | Y | N | N |
    Condition C | Y | N | Y | N | Y | N | Y | N |
    ---------------------------------------------
    Decision 1  |   | X | X |   |   |   |   |   |
    ...
    

Using this algorithm you can be sure you covered all combinations. It doesn’t matter how many conditions you have and you don’t even have to think :)

Thanks Manfred!

Tomahawk and Spring Webflow

Posted in java, software development on March 20th, 2009 by Joerg – Be the first to comment

I recently ran into a configuration problem when using Apache Tomahawk and Spring Webflow together. When using some of the more advanced components like <t:inputDate> I got an error message:

...
java.lang.IllegalStateException: ExtensionsFilter not correctly configured. JSF mapping missing.
...

I did configure the MyFacesExtensionsFilter like shown in the documentation but that was not enough:

 <filter>
    <filter-name>MyFacesExtensionsFilter</filter-name>
    <filter-class>org.apache.myfaces.webapp.filter.ExtensionsFilter</filter-class>
     ...
    </init-param>
  </filter>

  <filter-mapping>
    <filter-name>MyFacesExtensionsFilter</filter-name>
    <servlet-name>Faces Servlet</servlet-name>
  </filter-mapping>

After some debugging it turned out that this filter was never called. The solution is simple. When you combine Spring Webflow and JSF the Faces Servlet has no real function. It just needs to be there for some compatibility reasons. The real servlet that needs to be filtered is the Spring MVC Dispatcher Servlet. So you need to change the filter mapping like this:

<filter-mapping>
    <filter-name>MyFacesExtensionsFilter</filter-name>
    <servlet-name>Spring MVC Dispatcher Servlet</servlet-name>
</filter-mapping>

This also applies for all other filters that are usually applied to the faces servlet, like the Trinidad filter.

The Good, the Bad and the Ugly of one week sprints

Posted in agile, management, scrum on March 15th, 2009 by Joerg – Be the first to comment

I recently saw Bob Martins Keynote on Øredev. Around time index 14:30 he is talking about length of iterations. This reminded me on some experiences we made recently when trying sprints of one week in some of our teams. So here are some aspects we found.

The Good

  • Scrum zeremonies are done very often. The people on the teams were used to scrum, but the teams were new. So the training effect of doing planning, review and retrospectives so often was good. By the way, the zeremonies are proportionally shorter. There is no waste of time just because there done more often.
  • The short iterations gave a good feedback on where the project was going and how long this will take.
  • The focus is very high on completing the sprint-tasks, but this is not only a good side. See also the Ugly.
  • Teambuilding happens faster than with longer iterations. I think this is mainly, because teambuilding needs all phases of an iteration to be completed and shorter iterations mean the phases happen more often.

The Bad

  • Tasks need to be prepared very well. A one week iteration is not only challenging for the team. It is even more challenging for the product owner. Tasks need to be well prepared and small enough to fit into one week.
  • Some people on the team will not like such a short iteration. You need to get the commitment of everybody that they want to try this for a while.
  • Things that go wrong, hurt faster and harder. This is good as long as the real reason will be removed. But it is easy to think of the short iteration to be the problem instead of the real reason.

The Ugly

  • As already said, it is easy to get in a situation where the one week iteration is seen as the problem even if there are other reasons. This can remove this option for the future. So make sure the situation is ready, before you try.
  • People can feel like being in a hamster’s wheel. This prevents from taking a step back and seeing the whole picture. Short sprints can show a lot of problems in the process, but they can hide larger issues or prevent alternative approaches. Everybody just feels they have no time for it.

So what is your experience with one week sprints? Is it just like Uncle Bob says: “It takes a real man to do one week iterations”?

XML to POJO via Groovy

Posted in groovy, java, software development on March 8th, 2009 by Joerg – 9 Comments

Transforming data in XML to several Java-Objects is a pretty common task. There are a lot of technologies that support this. One example would be JAXB. It is also not uncommon that the structure of the original XML and the Java objects does not match. The obvious choice for XML transformation in such a situation would be XSLT.
There is another approach that uses Groovy to transform XML directly into a POJO structure in one step. I will show you how this looks like.

Lets assume, we have a XML-file like this:

<data>
  <person>
    <firstname>Otto</firstname>
    <lastname>Mueller</lastname>
    <street>Lange Strasse</street>
    <city>Berlin</city>
  </person>
  <financial>
    <netincome>120000</netincome>
  </financial>
</data>

The target structure are two POJOs that look like this:
Target Objects

Both structures differ. There are also some small conversions to do. The XML includes yearly income, where the POJOs needs monthly income. The POJOs contains a field for zipcode, but the XML does not deliver it.

So, here is the Groovy-Code that does all the transformation:

public class XmlTransformer
{

  Person transform(File xml)  //1
  {
    def xmlData = new XmlSlurper().parse(xml)   //2

    Person person = new Person()

    person.firstName = xmlData.person.firstname   //3
    person.lastName = xmlData.person.lastname

    Address address = new Address()
    address.city = xmlData.person.city
    address.street = xmlData.person.street
    address.zipCode = ZipCodeFinder.find(xmlData.person.city.toString(),   //4
            xmlData.person.street.toString())
    person.address = address

    BigInteger yearlyIncome = new BigInteger(xmlData.financial.netincome.toString())
    person.monthlyIncome = yearlyIncome.divide(12)  //5

    return person
  }

}

What happens in detail (numbers on the list match the numbers in code comments):

  1. This is a simple Groovy class that contains one method called transform. This method gets the XML-file as input and returns a Person object. The Person class itself is defined in Java.
  2. XMLSlurper  is the Groovy XML-Parser that allows the easy access to all xml elements. For more details on it see here.
  3. This uses some Groovy magic. On the left side we assign the value to the property firstName of the person object. This is a shortcut for using person.setFirstName(). On the right side we see the slurper at work to get us the XML value.
  4. We can call any Java-class from within the transformation code. Here we call an example helper-class, that would return a zipcode for a given city and street.
  5. Finally we also do some calculations within our transformation to convert the yearly income to a monthly value.

Groovy can be called from Java in several ways. If you do not need to change the transformation often I recommend to just compile the Groovy code. In that case it will be called from Java as if it would be Java code:

XmlTransformer transformer = new XmlTransformer();
Person person = transformer.transform(inputFile);

This kind of transformation code can easily be embedded into a Java project. There are several advantages, when using the Groovy method:

  • Just one step for transformation including conversions.
  • Easy debugging, when using an IDE like IntelliJ IDEA.
  • Java-like syntax, no learning of XSLT required.
  • Easy code-structuring. The transformation can use all features of a dynamic object-oriented language.
  • Simple unit-testing. If you split the code into several methods, you can test each logical unit using established frameworks like JUnit or TestNG.

So what is your opinion? What are your current methods of transforming XML to POJOs?