ParkCalc automation – A short reflection

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.

  • Print
  • Twitter
  • LinkedIn
  • Google Bookmarks

5 thoughts on “ParkCalc automation – A short reflection”

  1. I have this application here:

    Test Application
    I think some applications are harder to test automatically or even not feasible at all. Maybe I had some example with this.
    Anyway have to add that is a very good approach in your latest posts to basically give example on how to test.

    1. As James Bach pointed out, what’s the mission for testing there? Right now, I have to learn about the application and the domain as well. As domain knowledge serves test automation, I cannot automate learning domain knowledge – up until now. The app is interesting though, and I’m considering to run it through a session of EWT over the next few weekends maybe.

Leave a Reply

Your email address will not be published. Required fields are marked *