Thanks Marcin. This approach is working for me now. Regards, Sreelakshmi
On Saturday, December 17, 2016 at 4:43:49 PM UTC, Marcin Erdmann wrote: > > Hi Sreelakshmi, > > The key is in the following sentence from my previous email: "you would > pass lists of page classes consisting of a page for mobile and a page for > desktop to at(), click(), `to` option of content definitions, etc (see the > second example at http://www.gebish.org/manual/current/pages.html#to) and > check for desktop/mobile specific content in your at checkers." > > So you want to depend on your at checkers for mobile pages to return true > when you are on a mobile page and ones for desktop pages to return true > when you are on a desktop page and use variants of at(), click() and `to` > option of content definitions that take lists of classes. Your test > (ViewportSizeAgnosticSpec > in my example) then doesn't need to know if it's on a mobile page or a > desktop page, because thanks to abstracting the login action it doesn't > need to - the correct page type (mobile vs desktop) will already be set on > the Browser instance and thus the correct login method will be called. > > Marcin > > On Thu, Dec 15, 2016 at 12:50 PM, schakiyamurikunjappa via Geb User > Mailing List <[email protected] <javascript:>> wrote: > >> Hi Marcin, >> >> Can you please tell me how will this code avoid having separate tests for >> mobile and web. >> Though there is 'MobileLoginPage' and 'DesktopLoginPage', how to call the >> corresponding 'login' function based on the platform (desktop/mobile). >> I didn't understand how the class 'ViewportSizeAgnosticSpec' knows which >> login function is relevant based on the platform. >> I am trying to have one test which runs on web and mobile. >> >> Regards, >> Sreelakshmi >> >> On Wednesday, July 8, 2015 at 8:51:40 AM UTC+1, Marcin Erdmann wrote: >>> >>> Hi Edward, >>> >>> If you want to avoid duplication in having to write two sets of tests - >>> one for desktop and one for mobile - then you should probably abstract the >>> content by not interacting with it directly in your tests but by using >>> methods defined on pages and modules. Then you would pass lists of page >>> classes consisting of a page for mobile and a page for desktop to at(), >>> click(), `to` option of content definitions, etc (see the second example at >>> http://www.gebish.org/manual/current/pages.html#to) and check for >>> desktop/mobile specific content in your at checkers. >>> >>> It might look something like: >>> >>> class HomePage extends Page { >>> static content = { >>> loginPageLink(to: [DesktopLoginPage, MobileLoginPage]) { >>> $("a#to-login") } >>> } >>> } >>> >>> abstract class LoginPage extends Page { >>> static content = { >>> //content common to both desktop and mobile, if any >>> } >>> >>> abstract void login(String user, String password) >>> } >>> >>> class DesktopLoginPage extends LoginPage { >>> static at = { $(".visibleOnlyOnBigViewports").displayed >>> >>> static content = { >>> //content specific to desktop >>> } >>> >>> void login(String user, String password) { >>> // desktop specific implementation >>> } >>> } >>> >>> class MobileLoginPage extends LoginPage { >>> static at = { $(".visibleOnlyOnSmallViewports").displayed >>> >>> static content = { >>> //content specific to mobile >>> } >>> >>> void login(String user, String password) { >>> // mobile specific implementation >>> } >>> } >>> >>> class ViewportSizeAgnosticSpec extends GebSpec { >>> def "login"() { >>> when: >>> to Homepage >>> loginPageLink.click() >>> login("user", "secret") >>> >>> then: >>> ... >>> } >>> } >>> >>> There are many variations of this and you should adapt it as you go >>> based on what the differences actually are. If the login action is exactly >>> the same in both cases and it uses the same content then you can simply put >>> the implementation in the base class. If the action is the same but the >>> selectors for the content would differ, put the action in the base class, >>> and make it expect the subclasses to define content with given names. >>> >>> Then you can use config environments ( >>> http://www.gebish.org/manual/current/configuration.html#environment_sensitivity) >>> >>> to set different browser size to be able to test the desktop or mobile >>> version of your app (you can see how to change browser size at >>> http://blog.proxerd.pl/article/resizing-browser-window-in-geb-tests) >>> >>> On Tue, Jul 7, 2015 at 7:58 PM, Edward Pinchess < >>> [email protected]> wrote: >>> >>>> Hello, >>>> >>>> I've been using GEB and Spock successfully to write automated tests for >>>> Browsers and want to look at extending it to support >>>> different viewports for Mobile and Tablet. >>>> >>>> The site that I'm testing is based on responsive >>>> <https://en.wikipedia.org/wiki/Responsive_web_design> web design, >>>> which means that the structure and content varies depending on >>>> the screen size of the device. >>>> >>>> I'm wondering if someone else has extended their tests to support >>>> Mobile / Tablet and whether they have any recommendations. >>>> >>>> I have a number of Pages defined such as: >>>> - HomePage >>>> - SearchPage >>>> - LoginPage >>>> >>>> My idea was to extend the page definition to create a specific sub-page >>>> for Mobile / Tablet which defines specific content that >>>> differs from the desktop version i.e. >>>> >>>> class MobileHomePage extends Homepage. >>>> >>>> The advantage being its relatively simple, the downside being that >>>> I'll have to write new Spock tests that are specific for Mobile / Tablet. >>>> >>>> Thanks very much >>>> >>>> Edward >>>> >>>> >>>> >>>> >>>> -- >>>> 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 [email protected]. >>>> To post to this group, send email to [email protected]. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/geb-user/0924c465-fcae-4e7f-9ac0-2cbd7b7baeaf%40googlegroups.com >>>> >>>> <https://groups.google.com/d/msgid/geb-user/0924c465-fcae-4e7f-9ac0-2cbd7b7baeaf%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 [email protected] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/geb-user/f3b9faa4-2306-45dc-b356-d1ec77f446a6%40googlegroups.com >> >> <https://groups.google.com/d/msgid/geb-user/f3b9faa4-2306-45dc-b356-d1ec77f446a6%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 [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/geb-user/0a493a8a-dfc3-4c0b-aa06-16989215fa9b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
