Pages and navigation-related content

[Samuel Rossinovic]

Hi.

The app I am testing is a single page app. The various pages do not have their own urls. Rather, pages are browsed through a series of clicks on navigation buttons (selecting a main menu item, then selecting a sub-menu, etc). Building on a prev discussion, I have built the buttons as content in the page. This resulted in a set of Pages, all inheriting the common navigation content, as part of their parent Page. I am now trying to extend testing across to another app: very similar pages, but different navigation, so different menu/sub menu items.

The problem I'm facing now, is while I'd like to reuse the pages (at() verifiers & content), the navigation is baked-into the pages as content.

I think I'd be in a better situation had the pages been navigable through their url. Then, navigation is extracted-out to Browser.to() et al, and doesn't pollute the Page. Possibly someone who stumbled on a similar situation can suggest a solution: maybe somehow piggyback the navigation code onto Browser?

Thanks!

[Marcin Erdmann]

How about extracting the non-navigation related content to modules (one content module per page) and reusing that?

--
You received this message because you are subscribed to the Google Groups "Geb User Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to geb-user+unsubscribe@googlegroups.com.
To post to this group, send email to geb-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/geb-user/436fb583-3edd-487e-a247-6c50414ac048%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Samuel Rossinovic]

Hmm. Doing that won't avoid duplicating Pages (If I could externalize the navigation bits, I would only need the one Page class). Also, I think I cannot reuse the at() verification closure, only content.

Still - it's a good place to start from. I will have a look at implementing. Thanks!

On Wednesday, January 24, 2018 at 6:23:59 AM UTC+11, Marcin Erdmann wrote:

How about extracting the non-navigation related content to modules (one content module per page) and reusing that?

On Mon, Jan 22, 2018 at 5:59 AM, Samuel Rossinovic <samuel.r...@gmail.com> wrote:

Hi.

The app I am testing is a single page app. The various pages do not have their own urls. Rather, pages are browsed through a series of clicks on navigation buttons (selecting a main menu item, then selecting a sub-menu, etc). Building on a prev discussion, I have built the buttons as content in the page. This resulted in a set of Pages, all inheriting the common navigation content, as part of their parent Page. I am now trying to extend testing across to another app: very similar pages, but different navigation, so different menu/sub menu items.

The problem I'm facing now, is while I'd like to reuse the pages (at() verifiers & content), the navigation is baked-into the pages as content.

I think I'd be in a better situation had the pages been navigable through their url. Then, navigation is extracted-out to Browser.to() et al, and doesn't pollute the Page. Possibly someone who stumbled on a similar situation can suggest a solution: maybe somehow piggyback the navigation code onto Browser?

Thanks!

--
You received this message because you are subscribed to the Google Groups "Geb User Mailing List" group.

To unsubscribe from this group and stop receiving emails from it, send an email to geb-user+u...@googlegroups.com.

[Marcin Erdmann]

You probably could extract the navigation instead of content. It's just hard to provide the best guidance given that I only have part of the picture on my end. That's why I'm only giving you pointers and hopefully they will get you on the right track.

To unsubscribe from this group and stop receiving emails from it, send an email to geb-user+unsubscribe@googlegroups.com.

To post to this group, send email to geb-...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/geb-user/fccc57fe-1d00-4607-bb3b-5f61447484fc%40googlegroups.com.

[Samuel Rossinovic]

Here's how I'm currently tackling the issue of my original post:

* created a hierarchy of faux pages, containing just the navigation menu:

interface NavMenu
 PageA toPageA()
 PageB toPageB()
 //...
}


class AppXNavMenu extends Page implements NavMenu {
 //..
}


class AppYNavMenu extends Page implements NavMenu {
 //..
}

Then, in a Spec:

class SpecBase extends Specification {
    @Shared
    NavMenu navMenu


    def setupSpec() {
        /*
         * specs begin once user is signed-in
         */
        LoginPage loginPage = to LoginPage
        loginPage.login username, password
        navMenu = browser.page
    }
}

Now the navigation content is encapsulated in the faux pages, which leaves the real pages with just their 'business logic' content.

• LoginPage.login() employs a factory, which uses baseUrl to return the respective Page-derived class. 
  
• SpecBase.navMenu is only used to get around the app, with methods returning actual Page classes.
  

• I then divvied up Specs into common, AppX, AppY. I had to externalise management of baseUrl (I decided to let maven take charge of that, through profiles).
  

The above covers shared pages/specs nicely so-far.

One issue that I still haven't solved is with the App-specific specs: those specs see a NavMenu, whereas in-fact, they mostly need to access methods in the derived, app-specific page. That's because they mostly test app-specific pages. The tests still run ok, but I'd rather have the right type of Page available at compile time. Peppering the code with downcasts is not something I'm keen on doing. Would be happy to hear suggestions if anyone can offer. 

On Wednesday, January 24, 2018 at 7:49:26 PM UTC+11, Marcin Erdmann wrote:

You probably could extract the navigation instead of content. It's just hard to provide the best guidance given that I only have part of the picture on my end. That's why I'm only giving you pointers and hopefully they will get you on the right track.

On Wed, Jan 24, 2018 at 8:31 AM, Samuel Rossinovic <samuel.r...@gmail.com> wrote:

Hmm. Doing that won't avoid duplicating Pages (If I could externalize the navigation bits, I would only need the one Page class). Also, I think I cannot reuse the at() verification closure, only content.

Still - it's a good place to start from. I will have a look at implementing. Thanks!

On Wednesday, January 24, 2018 at 6:23:59 AM UTC+11, Marcin Erdmann wrote:

How about extracting the non-navigation related content to modules (one content module per page) and reusing that?

On Mon, Jan 22, 2018 at 5:59 AM, Samuel Rossinovic <samuel.r...@gmail.com> wrote:

Hi.

The app I am testing is a single page app. The various pages do not have their own urls. Rather, pages are browsed through a series of clicks on navigation buttons (selecting a main menu item, then selecting a sub-menu, etc). Building on a prev discussion, I have built the buttons as content in the page. This resulted in a set of Pages, all inheriting the common navigation content, as part of their parent Page. I am now trying to extend testing across to another app: very similar pages, but different navigation, so different menu/sub menu items.

The problem I'm facing now, is while I'd like to reuse the pages (at() verifiers & content), the navigation is baked-into the pages as content.

I think I'd be in a better situation had the pages been navigable through their url. Then, navigation is extracted-out to Browser.to() et al, and doesn't pollute the Page. Possibly someone who stumbled on a similar situation can suggest a solution: maybe somehow piggyback the navigation code onto Browser?

Thanks!

--
You received this message because you are subscribed to the Google Groups "Geb User Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to geb-user+u...@googlegroups.com.
To post to this group, send email to geb-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/geb-user/436fb583-3edd-487e-a247-6c50414ac048%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Geb User Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to geb-user+u...@googlegroups.com.
To post to this group, send email to geb-...@googlegroups.com.

[Marcin Erdmann]

I would probably explore making SpecBase abstract with abstract void setNavMenu(NavMenu navMenu) which can then be backed using an app-specific page field.

To unsubscribe from this group and stop receiving emails from it, send an email to geb-user+unsubscribe@googlegroups.com.

To post to this group, send email to geb-...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/geb-user/89715491-57b2-4155-82ac-0baedcf43bbc%40googlegroups.com.

[Samuel Rossinovic]

Hmm. Can you actually do that? override accessors to a @Shared field? Will try. Thanks!

[Samuel Rossinovic]

Also, I gather that would involve subclassing the abstract spec, one-per group of tests (AppX/AppY/common, in the case I described above), correct? Wouldn't that limit reuse of spec code? Say there's some functionality common to some of the tests across groups (like maximize the browser window at setupSpec, interact with configuration or do something else which is spec or browser-related). This added class level precludes such reuse: I'd either have to duplicate the NavMenu-setting code, or the common-functionality.