How should I organize a TestNG suite for Selenium 2 WebDriver tests that use page objects?

Question

I'm trying to organize a functional test suite for the UI in a CRUD web application using TestNG-style Selenium 2/WebDriver tests. I've isolated page-interaction logic into distinct page objects, and currently have one testing class with a big, inflexible, non-modular @Test method. The method navigates through my application's workflow, interacting with each page via its corresponding page object, making assertions about pages' state, etc.

This approach works at a basic level, but I would like to leverage TestNG's reporting capabilities more, and make my test suite more modular. My first attempt to do this has led me to try dividing up that one big @Test method such that distinct tasks in the application's workflow each get their own @Test method.

The problem with those more modular @Test methods is that I have them returning page objects. However, TestNG seems to ignore methods that don't return void, even if the method is annotated with @Test.

There's an example of how to properly leverage TestNG in Selenium 1 at http://testng.org/doc/selenium.html, but it doesn't use page objects. Ideally, I'd like to use page objects and have a testng.xml file set up similar to that in the linked example, where each @Test method builds on the result of the previously-listed @Test method, testing sequence-dependent tasks that make up a workflow.

Are there any open source examples of how I could accomplish this? Or would someone familiar with WebDriver/Java/TestNG/page objects be willing to show how the example at http://testng.org/doc/selenium.html could be reworked to use page objects while retaining TestNG's ability to report test-by-test results?

Answer 1

Given that you can't return a page object, you might have each test stuff its last page object into a member variable, so that the next test can access it.

This is ugly, of course, because it increases the dependence between tests, and does so in a not-exactly-obvious way. But the results might give ideas about what to do next. And if it's too ugly you can always revert.

Here's another possibility, which seems more complex than it's worth: Each test gets its starting page object from a factory, which determines which page object to create based on information it discovers from the browser (URL, title, some other info).