Everyone Else Is Doing It...

There are lots of different testing tools and frameworks out there. Maybe too many. We end up having to use a whole bunch of different tools to test different parts of our projects. In working on LiFT, we've found that for various reasons we're currently tied in to JUnit, and it's quite a lot of work to create a version for TestNG or other frameworks, or to integrate our acceptance tests with jMock etc. Because of these problems we're looking forward to the release of commons.testing, a framework agnostic API for writing tests. This upcoming release was the cause of a lot of buzz at the SPA conference last week.

With its extensive XML configuration support, commons.testing also aims to remove the dependency on writing code, allowing tests to be written by non-programmers. Again very well aligned with LiFT's goals. Look out for more information on this all-encompassing framework soon.

It seems that as the amount of content on the web grows, it becomes less and less efficient to surf around and look for interesting things. Where previously people would have their lists of sites that they would visit regularly to catch up on updates, more and more people are now setting up subscriptions and feeds so that they don't have to take the time to go and look if there is anything new.

Rather than going out hunting for new content, we want new content to come to us. We want it to be a push rather than a pull model. However, even with RSS feeds and the like, at the moment we are still polling our favourite sites at regular intervals, it's just that we have a machine to do it for us. Although we appear to be getting content pushed to us, we aren't really.

I think that the next step for the web is some sort of real push messaging for content, so in my browser I just set up a list of things that I'm interested in, and when new stuff is available, and I'm connected, it is piped to my machine for me to read. One of the things I read recently which reinforced this feeling was Tibco's sponsorship of the development of DWR. DWR is a framework for working with AJAX in web applications, and Tibco one of the big name vendors of messaging products.

Also, with the increase in the numbers of mobile devices used for internet access, push would seem to be a good fit. Connectivity for a mobile device is at best intermittent, and currently if I want to look at the news headlines when I'm out of signal range, I'm stuck. With a push model, my device can be updated asynchronously as I walk around in and out of signal areas, so I should have some reasonably fresh data whenever I look. It would be a substantial change to the way that the web has tradionally worked to push content to the browser, but I can feel it coming.

In planning our iteration's work at the beginning of this week, we used something simple but effective to focus on how many people were available, and who could work on what when. We drew up a simple calendar on a whiteboard showing when each person would be on holiday, and when people would be out of the office (at client meetings etc).





The effect that this had was that we were clearly able to think about estimating and committing to work suitable for the people available. For example, we can see that Raymond is not back from his Christmas break until Thursday. There were some tasks that he has the most relevant skills for, so our customer agreed that we should move these to next week, instead prioritising things that Kylie could start on, and pair with Raymond when he gets back. The graphical representation gave us something that clearly showed our resource constraints, and it clearly provided a basis for prioritisation that was easily accessible to the customer.

It was also easy for us to see how many person days we had available, and to know when the amount of work planned for the week was more than we could commit to. We also used the calendar to record release dates and other pieces of work that need to be done on fixed days. I like the simplicity and the focus that the calendar brings. I think we'll be keeping it.

So, it's been a while since I last posted anything here. It's been a busy few months and I'm just finding a little bit of time to catch up in the Christmas break. One of the major things that happened in the last couple of months was XPDay which we organised in London. The conference sold out (for the sixth year running) and thanks to everyone who came along and participated it was a great event.

One of the sessions that I enjoyed the most at the conference was Awesome Acceptance Testing presented by Dan North and Joe Walnes. Dan and Joe presented a number of different approaches to acceptance testing, and talked about what acceptance testing means for different people in the development process - often these are the same people wearing different hats at different times - customers, analysts, testers and developers. They distilled the subject to five key themes. To do acceptance testing effectively, you need: automation, a harness, a vocuabulary, a syntax, and to be capturing intent.

This last point seems very important, and in fact links together a number of different themes at the conference, and a number of different open source projects that are currently under development in the area of testing. We are trying to build tests that express their intent. The clearer they are about how the system is supposed to behave, the more use they are as a specification, and the easier it is for customers to validate them. How do we know that we are writing the right tests unless we can check them with the customer?

Also at XPDay, Tamara Petroff and I ran a workshop session on literate testing. The idea here was for customers and developers to work together to create tests for a given scenario that expressed their intention clearly enough that there could be a discussion between customer and developer focussed on the test. However, we provided a structure which meant that the resulting tests were of a form that could be readily automated, making them of direct use to the development team. Our literate testing work has resulted in the release of the LiFT framework which allows tests to be written in Java that read as natural language. At the moment the framework focusses on the web domain, but one of the things that we experimented with in the workshop was how tests for different domains might be written while maintaining the same overall structure.





Groups worked together assembling tests usings decks of cards that we provided with various keywords printed on them. The also had some blank cards available to that they could extend the vocubulary when they needed to. This is important, as to express intent clearly, we need to be able to write our tests using the language of the domain that we are working in. If we are restricted to a fixed vocabulary by our test framework, this is very limiting, and often leads to tests being written that talk about the technology used to solve the problem (e.g. user interface widgets) rather than activity that the user is trying to carry out with the system.





One of our exercises involved writing acceptance tests for a report to be produced in the form of a spreadsheet. Most of the printed cards that we had provided were tailored to the web domain, so the teams had to produce more cards with words to describe the spreadsheet domain. From the results (in the picture above) we can see that the parts of the vocabulary to do with assertion could be reused from one domain to another, but the types of things present in each domain were different, and this is where new cards needed to be written. The pattern of printed and handwritten cards in columns struck me as highlighting the structure that is provided by the test framework. This helps to guide us towards creating tests that are automatable, but at the same time giving us the freedom in vocubulary to express our intent.

While we are discussing this topic, there are a couple of other projects worth mentioning. The assertThat syntax that we use in LiFT originally came from Joe Walnes, and was built into jMock. Not the matching/constraints part of jMock has been extracted into its own extensible library, Hamcrest. This has recently seen its 1.0 release and is well worth checking out.

One of the reasons for the release of Hamcrest was the upcoming (sometime real soon now, apparently) release of an RC1 version of jMock2. Having used jMock2 for a couple of weeks now, there are a few things that make it feel so much better than the original jMock. They're difficult to describe, but it's now much easier to write your test first and use your IDE to reactively complete/generate the code you need to make the test pass. jMock2 also uses Hamcrest, and focuses on providing a syntax that makes tests easy to read.

I can see intentional programming becoming a theme for 2007 (although I probably don't mean exactly the same thing that Charles Simonyi does).

Recently I've been doing a bit of maintenance work on a few websites written in PHP. I've never really been a PHP programmer, but I can read existing code and search for examples of things I want to do on the web. One way or the other I can usually get to something that works, although it might involve some trial and error, and I doubt that what I create is the most elegant solution to the problem. While doing this it struck me that I know very few people who would profess to be PHP programmers, but a lot of people who have "done some PHP" - many people who work with PHP in the same way that I do. You know enough programming concepts to envisage what should be possible, and you can copy, paste and edit existing code to come up with a solution.

This seems very much in line with some of the things that James Noble and Robert Biddle talked about in their paper Notes on Postmodern Programming. Postmodern programming takes the view that things are often not designed and implemented in a consistent way from scratch, but more often created by integrating and reusing existing software components, or bits of them, and glueing them together to make something that works. This is a topic that will be explored further at PoMoPro, the first international conference on postmodern programming, to be held in London on the 25th of November.

Although I can see that a lot of software projects do follow these themes of combining various existing parts to produce a whole, and that there is a certain satisfaction and pragmatism to rigging something up as fast as possible that does the job, I have to say that I am probably something of a modernist at heart. I have a better feeling about a project when the overall design is consistent and elegant. I prefer those clean lines. But I suppose that this is horses for courses, and in some cases the best thing to do is bolt together what you can find, in other cases you might be better served by creating an overarching design.

Registration is now open for XP Day 6 in London on November 27-28. The programme is also now available on the website. There is a great set of sessions spread over two days on various aspects of agile development, from the hard core technical to the much more people focussed. Places are limited, and always sell out quickly, so make sure to register early.

I've written a fair bit about literate testing in the past. With some support from my current employer Kizoom, the framework I have been working on has now been published as open source on java.net. We've called it LiFT.

Here is the LiFT page on java.net. Please try it out and let us know if you have any feedback.

For more background, see the video of the presentation Tom White and I gave at the Google London Test Automation Conference.

Thanks to all who have contributed code and ideas to get us this far. We hope there is a bright future for LiFT.