Recently I was debugging my code and I could not see why my test was failing. It took me about 20 minutes to see that I violated one rule I try to follow. One assert per test.

After tweeting it I got some reaction ranging from ‘this is a very silly guideline’ to ‘Tests should test one thing. Often one assertion, but not always.’. I, of course, tend to agree the latter one.

So what’s in for you when you use one assert per test? What are the problems?

One the plus side:

1. If a tests fails, you know what is wrong.
2. You know how to name your test method, since you are just testing one thing.
3. It plays very nicely along with Test Driven Development, test and implement one feature at a time and make it work.
4. If you change one thing in your code, at best only one unit test will fail (ok, this one is hard but possible).
5. With multiple asserts you fix one assert which is broken and only then you see that the next one is broken too.

The other side:

1. You need to think more about the test setup, it should be possible to really just test one thing and mock the rest. Think, design for testability.
2. More (test) code.
3. It looks like it is easier to have multiple asserts.

I try to do one assert per test. Once in a while my code reviewer catches one of the multiple asserts per test. Some times this is ok, some times I fix it.

My rule is to have one assert per test almost every time. But try it at least.

And while on it, use a better assert lib. Both JUnit and TestNG Assert confuse the heck out of me. Ansgar introduced FEST Fluent Assertions Module to our team. Now my tests look something like:

  @Test
  public void testAddSubscriber() {
    TestEventSubscriber eventSubscriber = new TestEventSubscriber();
    eventPublisher.registerSubscriber(eventSubscriber);
    assertThat(eventPublisher.getEventSubscribers()).
       containsOnly(eventSubscriber);
  }

If you don’t know it, try it. I do like it.

Which thoughts do you have ?

Every Programmer needs to read books. Usually you would get some packages from Amazon (or your favorite retailer) and read through them.
Now with devices like the Kindle and iPad (and Nook and…) things will change. No more carrying around a couple of hundred pages of paper. Only some Megabytes on Gigabytes of storage. The displays nowadays are good enough and the battery is not a problem for the most part.

Now the tricky part, you want your books in a format which you can read on many devices. The obvious candidates are:

• PDF : Lots of books are available in pdf, be sure not to get DRM PDF. Not all reader software can show this.
• Kindle (.azw) : The Kindle Software is available for many devices (iPad, PC, Mac and of course Kindle devices).
• mobi : Some stuff is available in .mobi as well.
• ePub : This is also wide spread. A DRM’d version is also available. So make sure your reader is able to handle that.

The best choice is of course to get non protected (read non-drm) books. To me pdf, epub and azw (I know, drm) all look nice. It is just a question of your reading device.

Formats are important but and the end, where do I get my books?

I picked a few publisher and looked on what they provide. Amazon is a different thing anyway. I compare the prices to their Kindle format.

Manning – jQuery in Action

	Print Book	eBook	Amazon	Kindle
	$39.99 (+ PDF)	$24.55 (.epub, pdf, .mobi)	$29.69	Could not find Manning titles for Kindle

Wrox – Professional XMPP Programming with JavaScript and jQuery

	Print Book	eBook	Amazon	Kindle
	$49.99	$49.99 (pdf, could be DRM)	$31.49	$19.54

OReilly – 97 Things Every Programmer Should Know

	Print Book	eBook	Amazon	Kindle
	$29.99 ($32.99 Book + eBook)	$23.99 (Android, Mobi, PDF, ePub)	$19.79	$18.85

APress – Coders at Work

	Print Book	eBook	Amazon	Kindle
	$29.99	$20.99 (pdf)	$18.85	$19.79

Packt Publishing – Solr 1.4 Enterprise Search Server

	Print Book	eBook	Amazon	Kindle
	$40.49	$30.59 (pdf)	$35.39	Could not find any Packt titles for Kindle

Pragmatic Bookshelf – Programming Scala: Tackle Multi-Core Complexity on the JVM

	Print Book	eBook	Amazon	Kindle
	$34.95 ($43.75 book + pdf,mobi,epub)	$22.00 (pdf,mobi,epub)	$23.07	Could not find any titles for Kindle

Conclusion:

Amazon shines, if they can offer eBooks there are priced very low, sometimes even the printed book is cheaper then the publisher eBook. If you can cope with Amazons format, a Kindle (or a Kindle app) is the way to go. Instant download, sharing between devices, very nice. I can now carry around dozens of books which I get for very cheap.
Mannings and Wrox have Twitter accounts where they announce good discounts on printed and electronic books. Worth to checkout. APress eBooks are always 30% cheaper as the cover price of the printed one.
Most of the publishers do have an extensive part of their books available as eBoooks.

Getting the eBooks is especially nice for folks living outside the US, e.g. ’97 Things Every Programmer Should Know’ is listed for about $27 at Amazon Germany. So I save about 40%. I will buy more books now since they are now much cheaper and more accessible to me.

My reader is an iPad with iBooks for epubs, the Kindle app for Amazon’s selection and GoodReader for Pdf’s.

Does anybody have good or bad experience with eBooks?

A couple of month ago I had an idea for a small web app. But what does it take to do it ? Do you start with the back end or the front end (read server or client side) ? Typically I would start at the back end, get the domain right and then see how I can fit the UI in. If a programmer starts this way you end with the typical ‘the programmer did the GUI’ scenario. That’s not really what I wanted. Don’t think too much about the domain, just see what the needs of the end user are and get the UI done (right).

Trying frameworks …

But there you go, being a framework loving web developer, how do you do the UI, or better, in what technology? Among other I tried JSF 2 and I thought it’s cool. After a couple of hours I realized that this will slow me down. Fiddling with different ideas and concepts I just could not do that with JSF right away. I would have to write my own components. This is supposed to be very easy but still too much waste when I’m not sure if I even will use this.

Trying paper…

Next I started very basic and did some drawings. While this is all nice (I did it on my white board, I strongly recommend to do this on something you can erase) it turns out I had no idea on how to realize that in Html. I knew this must be possible somehow today but I had no idea what does it take to implement things like drag and drop, box scrolling, reordering and more. Nice thing I build on paper…but can I do it ?

The solution

What if I now combine those two approaches ? I needed some lightweight web framework, easy to learn (maybe one I already know) with quick turn around. After looking around for a couple of hours I came up with Html and jQuery.

I have some knowledge in Html and Css but I never did anything in Javascript or jQuery. So there is something new to learn. Since this was on my agenda anyway and I already bought Mannings jQuery in Action book in December I went this route. I hoped that adding jQuery into the page would give me some interactivity to the otherwise static Html page.

It turns out, it was the best choice. I came up with at least three completely different designs in a matter of evenings, got them to a working stage and could ‘feel’ how they would work (or not). After experiencing this I decided to do some substantial changes to the UI. Dragging and dropping is all nice and dandy, but it’s too much clicking and dragging for the app. On paper this really looked cool but in practice it was not.

It’s amazing what you can do with jQuery. You can save state on elements using Html 5 attribute, can load other Html snippets as Ajax responses and use a dozen jQuery plugins for menus, zooming, dragging and so on. Not to mention the power of jQuery itself. You can append action, animations or anything to any element. Without programming one line server side I got a fully working prototype running including adding and removing items, saving, loading and dynamic generated forms.

Some more iterations later (still not 100% happy) I started to implement it for real. Since I wanted to stay with that design (and very much Ajax oriented) I went the route of Direct Web Remoting and Freemarker. Freemarker will render my templates and DWR talks to my Spring beans. Whenever I needed to design another page I first did the standalone Html version, got it to a working state and then integrated it in the app.

Conclusion

Even if I would not have decided to use jQuery and pure Html for the final implementation (totally depends on the use case) I would strongly consider going the same route for doing the prototype again. It was so easy and the feedback was right there. I could throw away not working ideas and make new ones very easily. There was a learning curve using jQuery (and I needed to refresh my CSS) but it was time well invested.

How do you your prototypes? Fully integrated with your existing frameworks or on paper?

So I heard about these strange distributed version control systems like over a year ago. I used it in my own little projects and everything went smoothly and I really liked it.
The idea also caught on at work and my team started a using Git in a fresh project last summer. We did not had so much problems since you can use Git very much like a central vcs like Subversion if you want to.

Still, for all other code, we used Subversion.
We believe in agile and feature branches, so that’s what we do a lot. Every story has its own branch. If one story touches multiple code bases, that means multiple merge down/copy up’s.
At some point, in preparation for a sprint review, we found that code had disappeared from the trunk. Everything seems to work perfectly, just this feature was missing. Usually you would think if code was deleted, there would be at least one test failing and telling you that something is missing. But no, typing one wrong version number during merge down/copy up cut out the story very cleanly. Once we found the problem we could merged it back in from the not yet deleted feature branch.
Overall we managed to work with Subversion but it was a growing pain since we knew there was something better.

There are several advantages of distributed version control system which you all might have heard of already so I won’t go in to detail of this (of course there is also one major disadvantage: complexity). The main advantages for me are:

• Everything is local – very fast
• Merging is much much easier (or updating from another repo)
• Because merging is easier I tend to branch more often to try out ideas

Now, what does it take for my team to get Git going in all major code bases?

Technology

Here is our setup what we use at work:

• Windows PC, some Mac OS X
• IntelliJ Idea 9.0.x
• Teamcity 5.0.x
• Maven

The OS: Windows and Mac

Basically no surprise here. Works on both machines.

The IDE: IntelliJ Idea 9

Idea does support Git. I do like the approach which they took to simply use the git binary of your operating system. With the version control console you can see what Idea is doing. This way you can watch and learn. Back with subversion we had sometimes trouble using two different tools for handling subversion problems, like Idea and Tortoise SVN. Using the same tool for everything will make it easier.
The Git integration is not perfect but it does work well.

Continuous Integration: Teamcity

Teamcity does support Git the same way as Subversion. There is one drawback however: Pre-Tested checkins are not supported yet. This cool features allows you to run all tests before checking in. You will never have a broken branch/trunk if you use it! Basically it will take your changes to the code base, runs all tests and only commits them if everything passes. Sadly, it does not work with Git (yet, but you can vote for this feature).
Teamcity does allow you however to do a remote run with the changes you committed locally. So you check in everything locally and while Teamcity runs all the tests you can keep on coding. Running all tests with your current changes in the change list is also supported.
Teamcity uses JGit and has some limitations (like no tagging support). In Teamcity 5.1 they want to use the Git binary as well.

Another problem, which I will talk about in the next section, is agent side checkout.

Build Tool: Maven

Maven supports git as scm. Nothing more to say.

Since we are releasing our software every other week we automated the build process to two stages. Building the release and packaging different build artifacts. We used to have a button in Teamcity, push it and 30 minutes later we had a release. Unfortunately the way Teamcity supports Git is that the code which will get checkout does not have a .git directory (and for maven it is not under source control). I still wonder what the heck they are doing there. Without that, maven can not advance the version numbers in your pom and you are stuck. Please go and vote for this feature now. Thanks.
Until then we just do it like in the good old times and do a maven release from the command line.

People

While everything so far was technical, the biggest challenge might be mindset of the people and support from your friendly manager.

I’m lucky that my boss is very hands on and really liked that idea (also, since he was the one we usually asked if we yet again had problems with Subversion properties being messed up somehow). Otherwise you might need to do some ROI calculation why this really is a good idea.

What I encourage is that every team needs to have 1 or 2 people interested in git. The others in the team should see the benefit of it, even though they don’t know how git works. My advice would be that one person would give a 20 minutes presentation of what you can do with it to all interested co workers. We did not do it, but looking back, we should have done it. Make sure that you bring across the message that switching scm’s will not be that easy. If possible make everyone read the first 3 chapters of the freely available Pro Git book (and also buy a copy or two for the library). This will give them a much better understanding.
It is change and change usually causes some trouble. We got a team commitment for it so at least nobody was opposed to it. If a couple of people are not happy with the way how the new things are around here, they will have an easy time to make a loud and clear statement that switching to Git was a bad idea. Git is more complex but also more powerful.

I did a plan on how to migrate. This took me just a couple of hours.

• Which code bases to migrate
• Where to put the git repositories? Use the filesystem, SSH, Gitorius, Gitosis, Github:fi
• You might need more infrastructure, everybody needs ssh keys
• Any depended processes
• External collaborators
• When does operations have time to implement it
• Does the release process still work
• Continuous Integration System
• Test conversion of the subversion repository
• Access rights
• … there might be more I forgot about

Plan and test these as much as you can. We started to use git just to discover that we missed some use cases like our automated runs to check the external web service dependencies. Two people doing the planning certainly helps.

After start using it, we had one guy (me) who went around for the first 2-3 days and helped people with their git related problems. There will be problems, I promise!

We did migrate all of our code at once since we did not want to be stuck between two vcs’s. We will go with Gitorius and ssh based authentication. Since we do not have a server for that (yet) we use a shared drive for the time being as a repository. Being distributed it will be no problem for Git to change it’s location later on.

The first two of days were a bit tricky but it got much smoother after we all got used to it.

The work flow is different and it will take some time until everybody takes advantages of all the features like commit your files more often or make more private branches to try out ideas.
We started with a similar work flow we are used to and plan to introduce one feature of git at a time. This could have been better. Iron out the known commit habits with Git and make sure this works in your favorite IDE before hand. It is very important to make the transition a better experience.

We started just this month but we already had some nice effects like merging two branches with renamed files. On guy changed file and somebody else renamed the same file in his repository. As he merged in the changes, the change appeared in the renamed file. Really great.

Do you use a distributed version control system? How did your transition go ?

Developing software ain’t easy.

How do you know how you are doing ?

You could start collecting metrics about your code. These can give you some indication how maintainable and  reliable  it is.

The metric which come to mind to the most people is code coverage. Some people say it must be near 100%, other say 80% is a good number. At the end it can’t tell you if you are doing great or good. The only thing you might read from it is that a low number indicates a potential problem.

Duplication is another one you should look out for. A high number of duplicated code might bring up the problem that a bug was fixed in one place but lives on in other. If you are doing code generation (e.g. from WSDL’s) you might have a lot of duplicated code reported to you. A closer inspection is needed to really make sure this is a problem in the code you have written and is not auto generated.

Test success is not a metric you should be worried to much about. It just needs to be 100% at every checking in a shared repository. No discussion.

Cyclomatic complexity let’s you measure the number of linearly independent paths through your code. A high number means a more complex code. A complex code base is hard to maintain and involves a lot of work to adopt it to new requirements.

Dependencies between packages is another important value to check on (see Uncle Bob’s paper on Acyclic Dependency Principle). Basically it revolves around that packages should not have cyclic dependencies between them since this does have an impact on releasing and testing (and therefore coding). A change in one package could trigger a whole system build to make sure everything works together.

Tools like Findbugs let you define rules to which your code should comply to. This is great because it is tailored to your code/company and ensures you control and fine tune the measures. Or so. It requires some time to define these rules. They need to be refined over time and you have to understand them to make use of it. Of course you can leave out some of these and reduce complexity. Do not underestimate the effort to implement these.

This rounds up the metrics you can get from your code base.

But wait, there is more.

A valuable metric is the meantime between reporting a feature or bug and fixing. This gives your team (and management of course) a rough estimate how fast you can react to market changes.

To get an estimate of the mean time before a failure happens you can measure the time between two bugs. The higher the number the better. Current reported bugs per lines of code can also be measured. These metrics will give you some confidence in your code base.

At the end of the day the ultimate measure is the money on the company’s bank account. If this is not working out you are in trouble.

How to get all of these ?

There are some static code analysis tools to get you started. I only can talk about Java related tools but there are others as well.

• Checkstyle
• FindBugs
• PMD
• Cobertura
• Structure 101
• Sonar

To get more information about your bugs should query your bug tracking system like Jira or Bugzilla.

Summary

There are much more numbers out there but I think these are the ones you should always keep an eye on.

Look out for

• Code Coverage
• Duplication
• Cyclomatic complexity
• Cyclic dependencies
• Test success
• Time to market
• Mean time between failure

What metrics do you look out for ? Let me know in in the comments and why.

Whenever you create an object you have to find a meaningful name.

While renaming later in modern IDE’s is no problem at all you should not pick the first name which comes to your mind.

Imagine you have an external fraud detection web service and it will return a ‘hit’ or ‘miss’. How do you name this object? HitOrMiss maybe (since this is the representation you get from the webservice) ? It might describe the problem at hand. If you go with this name it will dripple down through all layers. The domain model, the dto’s, services and more will now reference to this object (and create their own derivates for it). Your colleagues which code up other parts of the system will refer to it and create their own variants of the name (like structure for web pages). The wrong name is now all over your code.

So much for refactoring in your IDE. You will never catch all the places automatically where the wrong name was used.

While it seemed lost time discussing the ‘right’ name for 5 minutes in the beginning it saves you much more time afterwards. Of course you might get also confused a couple of weeks later remembering what this thing really does and what it is used for.

Make sure you take time in naming your objects. A wrong decision can do some harm to your code. The later it turns out that the name was not correct the much more expensive it becomes to correct this mistake. If you are not really sure how to name it, talk to your colleagues and discuss the name. A second opinion can not hurt.

Maybe FraudDetectionResult would have been a better choice.

In Response to Matt Raible’s question about my preferred development stack.

Source control

In my own development project I switched to Git some time ago. I was using svn and before that cvs for a couple of years. Git just makes it easy to try out small ideas very quickly without reverting the code. We will introduce Git at work pretty soon (I hope).

The Atlassian cloud

I was using Confluence as a Wiki in my open source project and my current employer Hypoport uses it as well. Bug tracking is pretty much a task of Jira. Those two integrate very nicely. You can have ping backs in your Jira Ticket from Confluence, so you see all related files. I would love to use FishEye but I’m not sure how to justify the costs and what the added value is in our case.

The Code

I’m pretty much sold to Jetbrains IntelliJ Idea. I’m using it for 5 years now. With it comes Teamcity. It’s a very nice continuous integration tool where the biggest plus (among other things) is the delayed (and pre tested) checkin. No more late night checkins which break the master. We just rolled out the latest version which has a much nicer Git integration (so we can make the switch).

So it comes down to:

The List

• Source control: Git
• Wiki: Atlassian Confluence
• Continuous Integration: Jetbrains Teamcity
• Bugtracker: Atlassian Jira

We are about to use Sonar for code analysis and development over time, but this is just in the beginning.

What’s yours ?

If you want your Business Analyst to provide some acceptance tests for your implementation it would be best to make sure you get it in some form your tests can read. That way you can make sure your code does really do that what the customers wants.

Two tools to achieve that are Concordion and Cucumber (and cuke4duke). Both taking the approach of Fit a step further. You can find very good documentation for the tools on their web pages or as examples along with the code.

Concordion

Concordion let’s you write the specifications in html. You can instrument them with some Concordion code. Since the instrumentation code is in html, it is hidden when you render it.

<html xmlns:concordion="http://www.concordion.org/2007/concordion"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="http://www.concordion.org/2007/concordion ">
<body>
<p>
  <span concordion:execute="setCurrentTime(#TEXT)">09:00AM</span>
  The greeting for user <span concordion:set="#firstName">Bob</span>
  will be:
  <span concordion:assertEquals="greetingFor(#firstName)">Hello Bob!</span>
</p>
</body>
</html>

Concordion can instrument free text as well as tables to have some sort of data provider for tests. It integrates directly with JUnit (no TestNG support yet).

Concordion Specification/Fixture/System

The idea is that your specifications is stable. This will not change as much as maybe your code to fulfill the requirements of the customer. Your fixture bridges these two together.

package com.maxheapsize.concordion;
import org.concordion.integration.junit3.ConcordionTestCase;
public class DemoTest extends ConcordionTestCase {

    public String greetingFor(String firstName) {
        return "Hello " + firstName + "!";
    }

    public void setCurrentTime(String time) {
        System.out.println(time);
    }
}

Your java code provides the methods which are called from the specification. At that point you are most likely to use a DSL to build up your business logic. Concordion will assert the expected values.

After you run the unit test you will get a nice looking html page.

Concordion output

Passed tests will be green, failed red, pretty easy.

Pro Concordion:

• Instrumention of free text
• The final report is nice looking
• JUnit support
• Easy setup
• Pure Java

Con Concordion:

• The business analyst needs to know a little bit of html
• Usually the programmer needs to change the specification to instrument it
• You program parts in html, refactoring support is missing
• No TestNG support

Cucumber

Cucumber is a ruby based behaviour driven development tool. Since you can run Ruby code inside the JVM with the help of JRuby it is possible to use it for your Java code. The usually way so far is that you use maven or ant to startup JRuby and the Cucumber ruby code.

In Cucumber you write your specification (or feature) in plain english (or russian, german,lolcode or 36 or so more supported languages). No instrumentation is necessary but your customer has to stick to a certain layout (or better: structure). It follows the well known given-when-then pattern.

Feature: Demo

  Scenario: A Car with 4 wheels
    Given I have a car
    When I add 4 wheels
    Then I should be able to drive the car

You can write your step definitions (like the fixture in Concordion) with the help of annotations.

package com.maxheapsize.cucumber;

import cuke4duke.Given;
import cuke4duke.Then;
import cuke4duke.When;
import org.junit.Assert;

public class CarFeature {
  private Car car;
  @Given("I have a car")
  public void iHaveACar() {
    car = new Car();
  }

  @When("I add (\\d+) wheels")
  public void iAddWheels(int numberOfWheels) {
    car.setWheels(numberOfWheels);
  }

  @Then("I should be able to drive the car")
  public void iShouldBeAbleToDriveTheCar() {
    Assert.assertTrue(car.canDrive());
  }
}

The regular expressions defined in the annotations must match the feature definitions.

Cucumber results

You can define information in a table like structure as well to provide more data in an easy way. The given when then structure can be used to have multiple when’s or then’s. So it is very flexible that way.

Pro Cucumber

• Feature can be described in plain language
• No extra programmer work on he feature required
• Instrumentation is directly on the Java code via annotations

Con Cucumber

• More complex due to the Ruby/JRuby/Java chain
• Business analyst needs to stick to predefined format
• The only way (without extra work to write a runner) to run it seems to be within ant or maven, for rapid turn around and TDD I would like to have JUnit/TestNG support of some kind

Verdict

It is easy to get started with both tools. I spent about a couple of hours with each of them and was able to get simple and a bit more complex examples running. They get you going with BDD and acceptance based testing.

I like parts of both concepts. I want to be able to write a feature like in Cucumber. The instrumentation should be directly on my code and not in the part of the customer. The easy setup and integration of Concordion with JUnit (need TestNG here) and the output of it is very nice. So where is the tool which has these features .

So which tools will I use?

I have yet to see the use case where the business analyst writes the (and updates) the acceptance tests. I don’t mind add some extra code to the specification and I know html. I might get started with Concordion for now.

You might also check my post about Behavior driven development with EasyB (and vs. TestNG).

Do you use any of these tools? Or a different one? What’s your expierence?

We have been using our own flavor of Fit for Rules (which is build on top of fit) for about 1 1/2 years now to test our business logic written in JBoss Rules 5. It’s relatively easy to get the Business Analyst on board since he is using his tool (which is Microsoft Excel) to communicate test cases for the rules. So in theory, he writes the tests in Excel, we do the rules coding and voila, all tests turn green.

Reality is, we have to tweak the Excel sheets. We need to put in imports of our fact model, insert facts and create objects within that not so programmer friendly table environment. A couple of days ago we got the request to tweak some rules and we all had to start doing rules again (and we used to use Eclipse for writing rules because that’s the only IDE having a plugin for that).

After half a day of coding Java syntax in Excel sheets we decided that the ramp up time for the not so knowledgeable rules/fit programmers like me is too much. With debugging, copy and paste we spent easily 5-10 times more time on making the tests work than writing the code itself. Test driven design is not really an option here, since you need to know the imports of the rules file to get the sheet even to compile.

So what did we do ? Well why not try to get things working the way we used to do it ? TestNG anyone ?

There are many pros to use unit testing but also some cons. The biggest issue is that we will loose the direct communication to the business analyst. It’s always better if someone else writes the test and I just have to implement the solution. Maybe we can find another solution involving Active Spec or DSL. For now we stick to unit tests and the task the we have to make sure we convert every Excel test case to java code (but hey, that’s what our code reviews are for).

Checkout our current base class for testing our rules:

public abstract class AbstractRulesTest {
   public abstract String[] getRulesFileNames();
   private final String GET_FINDINGS = "import com.maxheapsize.RulesFinding;" +
                                                                           "query \"getAllRulesFindings\"\n" +
                                                                           "   finding : FRulesFinding()\n" +
                                                                           "end";

   private static Logger LOG = Logger.getLogger(AbstractRulesTest.class);

   public final List<FRulesFinding> fireRules(Set factsForWorkingMemory) {
       KnowledgeBase ruleBase = setUpKnowledgeBase();
       return fireRules(ruleBase, factsForWorkingMemory);
   }

   public KnowledgeBase setUpKnowledgeBase() {
       KnowledgeBaseConfiguration configuration = KnowledgeBaseFactory.newKnowledgeBaseConfiguration();
       KnowledgeBase ruleBase = KnowledgeBaseFactory.newKnowledgeBase(configuration);

       KnowledgeBuilder build = KnowledgeBuilderFactory.newKnowledgeBuilder();
       build.add(ResourceFactory.newReaderResource(new StringReader(GET_FINDINGS)), ResourceType.DRL);
       String[] fileNames = getRulesFileNames();
       for (String fileName : fileNames) {
           File userDefinedFile = new File(fileName);
           build.add(ResourceFactory.newFileResource(userDefinedFile), ResourceType.DRL);
       }

       handleBuilderErrors(build);

       ruleBase.addKnowledgePackages(build.getKnowledgePackages());
       return ruleBase;
   }

   private void handleBuilderErrors(KnowledgeBuilder build) {
       if (build.hasErrors()) {
           KnowledgeBuilderErrors knowledgeBuilderErrors = build.getErrors();
           for (KnowledgeBuilderError knowledgeBuilderError : knowledgeBuilderErrors) {
               int[] ints = knowledgeBuilderError.getErrorLines();
               LOG.error("Error at : "+ints[0]+" : "+ints[1]);
               LOG.error(knowledgeBuilderError.getMessage());
           }
       }
   }

   private List<FRulesFinding> fireRules(KnowledgeBase ruleBase, Set facts) {
       List<FRulesFinding> result = new ArrayList<FRulesFinding>();
       StatefulKnowledgeSession statefulSession = ruleBase.newStatefulKnowledgeSession();
       for (Object fact : facts) {
           statefulSession.insert(fact);
       }
       statefulSession.fireAllRules();

       QueryResults results = statefulSession.getQueryResults("getAllRulesFindings");
       try {
           FRulesFinding finding = (FRulesFinding) results.iterator().next().get("finding");
           result.add(finding);
       }
       catch (NoSuchElementException e) {
           result = new ArrayList<FRulesFinding>();
       }
      return result;
   }
}

All my rules insert a RulesFinding (and only one at the moment) into the working memory when triggered. The rest is pretty easy. You subclass it, overwrite getRulesFileNames and call fireRules with a set of objects (your tests) which need be insert into the working memory. To get the finding back you need to execute an already inserted query which needs to have an identifier (line 3, 20, 52, 54). It will contain the result of your rule execution.

Sample code would look like this:

public class RulesTest extends AbstractRulesTest {

   private Set facts;

   @BeforeMethod
   public void setUp() {
       facts = new HashSet();
   }

   @Override
   public String[] getRulesFileNames() {
       return new String[]{
               "src/main/rules/myrules.drl",
               "src/main/rules/generealRules.drl"
           };
  }

   @Test
   public void testDemoRule() {

       FMyFact myFact = new FMyFact();
    myFact.setColor("green");
       facts.add(myFact); // add all your facts here

       List<FRulesFinding> findings = fireRules(facts);
       Assert.assertTrue(findings.size() == 1);
       FRulesFinding finding = findings.get(0);
       Assert.assertTrue(finding.getStatus() == FStatus.OK);
   }
 }

Depending on how you cut your rules you can extract the assertion of the status.

Each test case in Excel now takes about 5-10 lines of java code. Considering we are covering each rule with about 5-15 test cases and boundary conditions this amounts to 75-150 lines of test code. I take that any day over programming in Excel.

At my current job management buys into Test driven development. It slowly starts to become our primary development style.

Some advantages of TDD for me are:

• Focus on problem solution
• No unnecessary development for use cases dreamed up by the developer
• Always make sure your code fulfills the requirements (tests)
• If you have tests you can safely refactor your code at any time

Even though we all knew about the advantages of TDD, we figured out that we do not always write tests first. While this might me acceptable in some situations like UI tests, most of the time it is not desired.
After seeing that problem for a couple of weeks (and always wondering how I did not write test first) all of the sudden I realized why sometimes it was easier to develop code with writing tests first and sometimes I just simply did not thought about it and had to write the tests later.

It’s simply because of pair programming.

What certainly happens to me when coding alone, is that sometimes I get into ‘crunch’ mode too fast. With a second person to slow me down, we are discussing the problem and make sure we both have the same understanding of what we are trying to achieve. During this process it is much clearer what needs to be done and what the goals are. This is a very important step. If I’m all by myself, I start writing down some classes, look at methods and I’m already thinking in code and not about the problem. Once you know what the real problem is, it is very easy to start writing your tests first. It helped me a lot.

Where pairing also helps is to focus both programmers to stay in TDD mode. Once the driver of the pair programming couple starts to hack away code, the other will remind him to write the tests first. This is a very valuable.

After a while I got better at test driven development, even programming alone.

So if you recognize that you do not write tests first (but you want to) and you yet again don’t know how that happened, try pair programming. You learn how to start with TDD (and get used to it) and get all the benefits of pair programming as well.