Take the 2-minute tour ×
Software Quality Assurance & Testing Stack Exchange is a question and answer site for software quality control experts, automation engineers, and software testers. It's 100% free, no registration required.

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?

share|improve this question
add comment

1 Answer 1

up vote 1 down vote accepted

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).

share|improve this answer
    
These sound like good ideas. I'll try them and let you know how it goes. –  jqp Sep 23 '11 at 19:48
    
It works! I went with the first approach you mentioned, which in hindsight I should have been able to think up. Thank you! –  jqp Sep 23 '11 at 20:33
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.