Iptor

It occurred to me that I should mention that I now work for Iptor Konsult AB rather than IBS JavaSolutions. This is not due to my changing jobs, rather that IBS decided that since we don't do the same things as the rest of the company, we should have a separate name and image. We are even going to be a separate legal entity, although still wholly owned by IBS.

I think it's a very positive development for both parties, and I personally am much more comfortable standing up and presenting myself as from Iptor than I ever was when it was IBS JavaSolutions. For a start it's not also the name of a rather unpleasant illness, and secondly it means I can avoid mentioning Java. A language I now work with daily, but don't enjoy nearly so much as python.

In practice though, the name change probably won't make that much difference in my daily life.

TextTest progress

When I wrote this post about the public Texttest nightjob statistics, I thought they were a bit confusing and hard to understand. Geoff has now rewritten the page to contain fewer numbers, and just report the passed and failed tests from the previous night. I think it's a bit easier to read now. He has also ditched about 500 tests that were running on Solaris, since that platform is not used often, and these tests never found bugs that weren't also found on Linux.

The statistics are still pretty impressive though, don't you think?

TestNG - my opinions

It's Java Forum next week, here in Göteborg. I'm giving a short talk about TestNG, a tool I've been using lately.

My basic conclusion is that TestNG is a very easy step from JUnit, and one you don't need to take if all your tests are true unit tests (ie fast and independant). TestNG has some nice features which help when your tests are slow and/or have external dependencies, especially if they are mixed together in the same test classes as true unit tests. I think it's pretty useful for unit and integration tests. (aka quadrant 1, technology facing).

Having said that, what bothers me about TestNG is that it means your test code is written in Java. For me, that makes it unsuitable for for system tests, (aka quadrant 2, business facing). If you have anything resembling an involved customer, you're going to at least want to encourage them to read the system tests to verify they are correct, and to gain confidence that the system is working. Truly agile teams have these people helping write tests. Many customer types won't be happy working with Java. You might be able to get by, though, if you have descriptive test names, good javadoc, and test data in separate files that they can read.

Rather than spending time learning TestNG, I think you may get more payback from tools such as Fitnesse, Robot or TextTest, which all allow you to get customers involved in reading and even writing tests. I think it could be a perfectly sensible choice to stick with JUnit for unit tests, and use one of these tools for both integration and system tests. What you choose will of course depends on the situation, for example the size of the system, the nature of the test data, and how many tools your team is willing to learn.

Video of "Varför går man till en Coding Dojo?"

I spoke at Smidig2009 about a month ago, and they have now put up videos of all the talks. So I just had the uncanny experience of watching myself speak (here is a link to it). I'm sure my swedish accent sounds better in my head when I'm talking, but I do apparently get my point across, since about a dozen people turned up to do a code kata with me in the open space in the afternoon.

JFokus

I've just heard that I've been accepted as a speaker at JFokus, in Stockholm in January. I'll be saying something about how to write good tests using Selenium, a tool I've been using a fair amount lately. I'm looking forward to the chance to meet up with the wider Java community in Sweden and find out what's new and what's hot.