First let me suggest reading Growing Object-Oriented Software, Guided by Tests by Steve Freeman and Nat Pryce. It's by far the best software testing book I read so far. What's great about it is that the authors don't focus on dummy use cases like Calculator
class and using TDD to test add(int, int)
method. This is silly. Instead they build fully-functioning application with Swing interface, network connectivity via XMPP and quite a lot of business logic. Which brings us back to your question.
Authors of the book above use various techniques and tools but they keep TDD practices all the time. For unit tests they go for mockito but for acceptance and integration tests they actually automate starting an application (GUI) and XMPP test server.
They managed to test-drive GUI tests by employing high separation between the test and GUI. You should hide your user interface (web, desktop, SOAP web service, etc.) behind an abstraction called driver. Your test interacts only with the driver using high level methods like placeOrder("Foo")
. Each driver (BrowserDriver
, SwingDriver
) understand what that means and either browses your web page or clicks buttons on fat GUI.
If you can change your GUI without changing test but only by changing underlying driver - you got it right.
See also
- Page Objects - keeping Selenium tests maintainable
- FitNesse