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.