JCranky’s Blog!

Hello everybody!

A few days ago, while I was searching for ways to improve the tests in our projects, I found an interesting article with some ideas. The main concept was to make the tests behavior, data and actual implementation separated. The original article can be found here. In this post, I’ll talk about the first of those things we decided to implement here: getting the data separated from the tests implementations.

First, if the data is not to be inside the test implementation, it ought to be somewhere. Where should it be? The answer is anywhere you decide it is easy to change. Better yet if it can be changed by non-programmers as well. In our case (and in the mentioned article’s example) we are using Excel spreadsheets.

Here is an example of how this looks like:

Data in an excel spreadsheet

It is most likely that almost anyone can edit this file. So if you have someone that is not involved in programming (like a client), this person should be able to edit this spreadsheet pretty easily.

After having the data ready, you need to access it somehow. To do this, we are using the Apache POI project, which makes accessing and reading this file (and any other MS Office files) pretty easy. The code bellow would read all cells in the spreadsheet and print them out.

HSSFWorkbook wb = new HSSFWorkbook(new FileInputStream(fileName));
HSSFSheet sheet = wb.getSheet(sheetName);

for (Iterator<HSSFRow> rit = sheet.rowIterator(); rit.hasNext(); ) {
  HSSFRow row = rit.next();
  for (Iterator<HSSFCell> cit = row.cellIterator(); cit.hasNext(); ) {
    HSSFCell cell = cit.next();
    System.out.println(cell.toString() + " ");
  }
  System.out.println();
}

Now, if you want to know if the correct user listing is being returned from some business logic implementation, you would only need to change that code to compare the results read from the files with the ones returned from your business class. The business rules changed? Change the file and the new expectation will be in place, without even having to touch the test code, unless of course it is a change in the structure of the information.

The next problem that my arise is that you probably have a LOT of tests. Or at least you should have… Anyway, having a spreadsheet for each one would be suicide. Tons of files to handle! So what we can do is to create one spreadsheet per test class. Inside the file, we create one sheet per test. The footer of the spreadsheet then looks like this:

Multiple sheets in a spreadsheet

And that’s it! What do you think? Any ideas on how to improve this even more? Don’t be shy and post a comment!