Yeah i bet it is! Thanks anyways! :)
Gergely. 2010/4/21 Jonathan Share <[email protected]> > To be honest I don't remember where I saw that technique first, but it > is pretty useful. > > On 21 April 2010 14:04, Gergely Brautigam <[email protected]> wrote: > > This is totally unrelated but i have to say that this: > > if (["yes", "true"].contains(stopOnAssert)) { > > that's pretty awesome :D I never saw something like this or never have > > thought about it either. Where did you get this kind of checking? > > Gergely. > > > > 2010/4/21 Jonathan Share <[email protected]> > >> > >> I already have calls to the following method scattered all over the > >> place whenever I expect the page to have changed (also gives me a way > >> of stepping through a test without resorting to a debugger) > >> > >> protected void assertFormPresent(String elementName) { > >> def stopOnAssert = > >> System.properties.getProperty("stopOnAssertForm", > >> "false").toLowerCase() > >> if (["yes", "true"].contains(stopOnAssert)) { > >> print "Push enter to continue test" > >> new BufferedReader(new InputStreamReader(System.in), > >> 1).readLine() > >> } > >> > >> if (!isElementPresent(elementName)) { > >> def reportedErrors = getValidationErrors() > >> if (reportedErrors.isEmpty()) { > >> fail "Did not find the expected form ${elementName}" > >> } else { > >> fail "Did not find the expected form ${elementName}, > >> looks like validation of previous form failed ${reportedErrors}" > >> } > >> } > >> } > >> > >> I could make this neater by throwing in a call to this method at the > >> end of the defineUI method, then I know that the class is always ready > >> for use once it is set up. > >> > >> I think I'm also leaning in favour of Solution 2 right now. > >> > >> Regards, > >> > >> Jonathan > >> > >> On 21 April 2010 13:20, Harihara Vinayakaram <[email protected]> wrote: > >> > 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]<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]<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]<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]<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.
