TDD requires a leap of faith

Software, Testing 1 Comment »

This week I did a presentation on Test Driven Development (TDD) at a client to a group of mid to senior level developers that are trying to up-skill in Java. I chose a few academic examples encompassing unit, integration and functional testing and demonstrated ‘live’ on Eclipse how I’d go about developing using a test-first approach. After completing the exercises I showed that with good test coverage I could refactor safely to improve the design.

The response from the audience varied from stunned thoughtful silence to scepticism to plain disbelief. I didn’t get a sense that anyone ‘got it’ to a point where they would go and develop their next class test-first. There was certainly lots of interesting discussion and questions afterwards but I think it all sounded like a bit of a hippy concept to them.

The experience made me reflect back on my adoption of TDD. I’ve been writing tests for years but it wasn’t till about a year ago that I took the leap of faith to a truly test-first approach. The trigger for me was some pairing sessions with experienced developers that showed me the value of it. For years before that I had resisted, in my mind always thinking that there was little difference between test-first and what I was doing.

TDD is a hard concept to sell, it sounds backwards to a developer that has been writing classes forever and has only recently started writing tests at all. Some of the comments I got during the presentation were: ‘I get tired of writing tests, it’s monotonous’, ‘Isn’t it better to write all the code and then give it to someone else to write the tests?’, ‘Wouldn’t TDD end up with a bad overall design since we’re always doing the least we can to make a single test pass?’, ‘We’re always under the pump, all this testing takes too long’. Academic answers to these questions sound shallow because it’s hard to explain what doing good TDD feels like. A few solid pairing sessions would provide a more robust answer to all these questions.

Throughout the presentation I couldn’t help but feel like a bit of a preacher. I know TDD is good, I wouldn’t develop any other way. But how do I qualify the benefits and convince someone that it’s the way to go? In the end, TDD requires a leap of faith. After some experience with it, you won’t turn back.

Selenium page models

Java, Software, Testing No Comments »

Brittle Selenium test suites are a common problem for projects with a significant number of acceptance tests. In the past, Selenese made it really hard to write well factored Selenium tests. The best one could do was write Selenium tests in JSPs and use JSP includes to avoid repetition of command chains (e.g. include Login.jsp).

Selenium RC gives us the ability to leverage the richness of the language to write well factored tests. One pattern that can help here is Page Models. These are essentially an abstraction of the pages in the application using classes. Taking Google as a sample application, we could write simple page models for the home and search results pages.

The page models provide access to page elements and are linked through navigation actions. We can use the page models to write tests that are more intentional and don’t interact with Selenium directly.

For more than one test class we would probably go a bit further and move the setUp and tearDown methods to a common parent or utility class. We could even make the page models reference the Selenium object directly rather than passing it around all the time.

With this approach the application and page models can be changed freely without having an impact on individual tests.

© 2007 Tomas Varsavsky, All Rights Reserved. WP Theme & Icons by N.Design Studio
Entries RSS Comments RSS Log in