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].
For more options, visit this group at
http://groups.google.com/group/tellurium-users?hl=en.
