Over the course of the past week or so, I wrote some blog entries on ParkCalc automation. Today I decided it’s time for a brief wrap-up on what I learned over the course. You can find the four parts written up so far here:
Getting started, Refactoring a data-driven test, Refactoring a keyword-driven test, BDD style tests

Extract variable until you drop

As mentioned earlier already, I learned that I did not know everything as I initially thought. That’s ok, that’s why we call these activities development. Sometime we develop code, sometimes we develop tests, sometimes we develop ourselves.

What I learned from Dale Emery is that for really good automated acceptance tests I may need to extract more and more variables to the point where it no longer makes sense. The advantage of variables, is that you may override them very easily thereby maybe replacing the complete user interface, or just putting a different id to a field that holds the costs. RobotFramework as well as FitNesse and the other common frameworks make these type of changes very easy, once you know how.

I will stop learning when I’m dead

I created another example using template tests as Pekka pointed out in one of the comments. I couldn’t make it run smoothly, so I continued with the BDD style tests. This is just fine for me, but I would have loved to see templates in action.

The BDD style tests worked very smoothly, and in fact I used a similar approach last year using this style. Most of the time I find the given, when, then style of BDD tests too noisy, as I need to product too much text in order to get going. This is a personal preference from myself, and I’m sure there are others out there who might like them. It’s critical to decide what serves the project in this case, and get in touch with the customer on the preferred written form.

You never stop learning

This is another obvious lesson. Initially I thought I new pretty much about test automation. Over the course of the write-ups I learned more and more from the contributors, on the mailing lists, and from the documentation of the tools I used. This was really fun – for me as well as for some of my visitors, as I got some pretty good feedback.

So, that said, I would love to conclude the RobotFramework part of the ParkCalc test automation with the template tests, but will start to take a closer look on Selenesse. Selenesse is a library for FitNesse, which provides similar capabilities as the RobotFramework Selenium library. If you, my dear read, got some other recommendations on what to try out next, drop me a line. As I love to learn new things, I would be happy to try something new out as well.