At ThoughtWorks, we’ve had a strong tradition of innovation with functional testing, with tools like Selenium, Sahi and Frankenstein. A precursor to FIT was born on one of our projects (incidentally, this was also the project where CruiseControl was born). We’ve always viewed testing as a collaborative, team activity, involving domain experts, developers, and testers. However, we believe that we have a long way to go before we achieve testing nirvana.

The current set of functional testing tools all have their own strengths, weaknesses, and gotchas. With GUI drivers such as Selenium, for example, it is quite critical to build abstractions. Without abstraction, test suites tend to rapidly become unmaintainable. Test code is code, after all – and it needs the same tender loving care that production code does. (I will be going into more detail about this in my future posts). Doug Seller’s talk at the Google Testing Conference is a great example of what’s possible with the right level of abstraction.

Tools from the FIT family are great for expressing intent, which aids collaboration between domain experts and the development team. However, the cost of maintaining these tests can often be prohibitively high. Nat Pryce has a great post on the issues to consider while using FIT here. FIT often isn’t used appropriately – James Shore’s rant about misusing FIT goes into a lot more detail about how this tends to happen.

Over the past decade, development tools have got more and more sophisticated. With automated refactoring support, tool integration, and extensibility, IDEs such as IntelliJ and Eclipse make it possible to work with large code bases. In contrast, however, functional testing tools seem to have missed the party.

We believe that the time is right for a next generation functional testing tool. The Agile community recently held a workshop on next generation functional testing tools. Meanwhile, a team at ThoughtWorks Studios has been hard at work too, and we believe we do have something that pushes the envelope of functional testing. We want to make higher levels of abstraction easier to create. We want testers to be able to richly express their intent. And, we’d like to provide the tool support to help teams do all that while treating tests like code. Stay tuned, and fasten your seat belts!