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

On Tuesday, February 13, 2018 at 7:32:10 AM UTC+11, Marcin Erdmann wrote:
>
> I would probably explore making SpecBase abstract with abstract void 
> setNavMenu(NavMenu navMenu) which can then be backed using an app-specific 
> page field.
>
> On Mon, Feb 12, 2018 at 9:12 AM, Samuel Rossinovic <samuel.r...@gmail.com 
> <javascript:>> wrote:
>
>> 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 
>>>>>> <https://groups.google.com/d/msg/geb-user/YArbpe-aWzc/mrSQSAasCgAJ>, 
>>>>>> 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
>>>>>>  
>>>>>> <https://groups.google.com/d/msgid/geb-user/436fb583-3edd-487e-a247-6c50414ac048%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>>>> .
>>>>>> 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.
>>>> To view this discussion on the web visit 
>>>> https://groups.google.com/d/msgid/geb-user/fccc57fe-1d00-4607-bb3b-5f61447484fc%40googlegroups.com
>>>>  
>>>> <https://groups.google.com/d/msgid/geb-user/fccc57fe-1d00-4607-bb3b-5f61447484fc%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>> .
>>>>
>>>> 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 <javascript:>.
>> To post to this group, send email to geb-...@googlegroups.com 
>> <javascript:>.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/geb-user/89715491-57b2-4155-82ac-0baedcf43bbc%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/geb-user/89715491-57b2-4155-82ac-0baedcf43bbc%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>> 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+unsubscr...@googlegroups.com.
To post to this group, send email to geb-user@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/geb-user/2e36691b-2ac5-4288-8cc6-1c5e3ed80c93%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to