In case of Solution 2) how will you handle failure cases ? In the sense that
you reach a different page than the intended page.

Also I feel Solution 2) is neater than Solution 1)

Regards
Hari

On Wed, Apr 21, 2010 at 4:10 PM, Jonathan Share <[email protected]> wrote:

> Hi,
>
> Background: I'm writing tests for an online ordering system. In order
> to perform a booking the user must go through 9 steps, some of these
> steps are optional based upon the search criteria entered. The test
> cases and parameters I need to fill the different stages are defined
> in an excel file. I have now managed to implement the whole process,
> however...
>
> Problem: I have ended up with having all of my ui for the whole
> workflow and methods for interacting with it defined in one huge
> class, with 520 lines in my defineUI() method and a further 1000 lines
> of helper methods for interacting with the ui. I'm thinking of
> breaking this down into one class per step in the workflow to make it
> more manageable, however I'm a little uncertain of how I should handle
> the instantiation of the model for the "next" screen.
>
> Question: Has anyone else implemented test cases of this type? How
> have you managed splitting up of the code and transitioning from
> screen to screen?
>
> As far as I can see at the moment there are two possible architectures
> I can choose from:
>
> Solution 1: Performing an action that causes a transition to another
> page returns the module for the next screen.
>
> class SearchPage extends DslContext {
>  def defineUI() { /*  */ }
>  def searchReturnTrip(Date outboundDate, Date returnDate) {
>    // Fill in search form
>    // click search
>    def searchResultPage = new SearchResultPage()
>    searchResultPage.defineUI()
>    return searchResultPage
>  }
> }
>
> class SearchResultPage extends DslContext {
>  def defineUI() { /*  */ }
>  def chooseFirstResult() { /* */ }
> }
>
> class TestCase {
>  void testMethod() {
>    def currentPage = new SearchPage()
>    currentPage.defineUI()
>    currentPage = currentPage.searchReturnTrip(new Date() + 1, new Date() +
> 5)
>    currentPage = currentPage.chooseFirstResult()
>  }
> }
>
> This seems like it will produce cleaner code in my main TestCase class
> however it will get ugly int the *Page classes when handling cases of
> the optional screens as you need to find out which screen you have
> come to in order to determine which *Page class to instantiate.
>
> Solution 2: Always instanciate the expected *Page class in the TestCase;
>
> class SearchPage extends DslContext {
>  def defineUI() { /*  */ }
>  def searchReturnTrip(Date outboundDate, Date returnDate) {
>    // Fill in search form
>    // click search
>  }
> }
>
> class SearchResultPage extends DslContext {
>  def defineUI() { /*  */ }
>  def chooseFirstResult() { /* */ }
> }
>
> class TestCase {
>  void testMethod() {
>    def searchPage = new SearchPage()
>    searchPage.defineUI()
>    searchPage.searchReturnTrip(new Date() + 1, new Date() + 5)
>
>    def resultPage = new SearchResultPage()
>    resultPage.defineUI()
>    resultPage.chooseFirstResult()
>  }
> }
>
> This solution leaves the decision of which page should be next to the
> TestCase (where we have enough information to make the decision of
> what comes next) however I feel that littering the code with the
> instantiation of new *Page objects will be less readable than the
> first solution.
>
> Does anyone have any comments/guidance on these options that lie before me?
>
> Thanks in advance,
>
> Jonathan
>
> --
> You received this message because you are subscribed to the Google Groups
> "tellurium-users" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected]<tellurium-users%[email protected]>
> .
> For more options, visit this group at
> http://groups.google.com/group/tellurium-users?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"tellurium-users" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/tellurium-users?hl=en.

Reply via email to