Tag Archives: test

TDD Talk at UMC

Yesterday I gave a speech, with two friends, about Test Driven Development at UMC, here in Mogi das Cruzes – SP – Brazil. The talk was nice, and this post is just to thank Claudinho and Fabio, the two friends mentioned previously, and Rodrigo Rocha and the University, for providing the space.

Thank you all =)


Software Quality and Agile

Often when we talk about agile software development, we mention how important quality is. In this post, I’ll run quickly through some thoughts and practices on how agile tries to guarantee this so-called higher quality.

When I first started using agile (eXtreme Programming in my case), one of the things that called for my attention the most was its focus on Accuracy and in avoiding Waste. This means that when developing software using an agile methodology, we always try to build exactly what the client/user want. Nothing less, nothing more. Having developed some things before using methodologies closer to traditional ones, I was urging for someway to stop doing useless work and wasting time (diagrams that would never be touched again anyone?). Agile seemed to be a good bet.

But this all is a little bit abstract. Like I said here, this is just saying that we will try to bring the most value to the client. Now looking into something more practical, there are some interesting things that we can use in a daily basis that also help us improve software quality, among them:

  • Pair Programming: two developers, instead of one, work together to solve problems. I talked previously about this here.
  • Pair Rotation: to avoid that the pairs get “accustomed” to its pair, we can constantly change the pairs that works together. This also helps leveling up the team knowledge and experience.
  • Tests: this is another invaluable practice that should be done in a daily basis. There is too much to sum up in a few lines. I’ll just mention two types of tests: unit and acceptance. We use unit tests to make sure the each individual feature of a system is working, and acceptance tests to guarantee that the whole system is ok, from a perspective similar to what the actual users have.

That’s it for now. I have a few other topics to write about in the pipeline, but if you have any ideas / suggestions for things you would like to see here, please don’t exitate to post a comment!

Bye!


Getting the data out of the tests

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

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

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!


Follow

Get every new post delivered to your Inbox.