Call verifyPage() automatically when a page object is accessed from another page object

[kenden]

This is a follow up feature request, I created this issue to avoid polluting Pull Requests (links below).

The idea is: "what if we called verifyPage() automatically when a page object is accessed from another page object (but not if it's created with a factory)?"
from #15 (comment)

I saw this comment in another PR:
"too many things to go wrong. I think it's better to leave it up to the end user. Especially because it also needs to be called from the open() method."
from https://github.com/sensiolabs/BehatPageObjectExtension/pull/30/files#r12889856

But it would be really nice to call all verify() functions automatically when accessing a page object with getPage() from another object.

The way I have it working now is to have all my page object inherit BasePageObject which has
$this->verifyResponse();
$this->verifyPageUrl();
$this->verifyPage();
in its constructor.

However, that means I can't use open() anymore (because when calling open(), the constructor is called first, and the url is not set yet). So I have to create functions in my context file to set the url first.
Maybe changing the getPage() function...?

[gggeek]

I think this highlights the underlying problem of pageObjects: they disconnect the act of "navigating to an url" from the creation of the pageObject itself.

While there are many good things to them, this can be imho source of confusion:

• I have seen code where the developers missed this subtlety, and basically loaded every page twice, making the testing process extra slow
• it seems that in your case you want the navigation act to always happen as soon as the pageObject is created, subverting the standard execution model (this would likely break tests of everyone else)
• otoh what is the status of a pageObject which is never opened, is it limbo?
• the pageObject docs encourage developers to navigate from page A to page B by creating pageObjectB and calling open() on it, but what about navigating to an unknown page by e.g. following a link? Creating the pageObject first does not seem to fit well, unless a reverse-routing-matcher is implemented
• it is not extra easy to reuse the "current page" in subsequent steps in the scenario, unless you create your own means of sharing pageObject instances (this might mostly be because the devs tend to subclass either MinkContext or pageObject context, but not both)
• it does not seem very easy to mix pageObject-based code and mink-session-based code. This leads to devs reimplementing in pageObject subclasses all the things which are available by default in the MinkContext

Maybe instead of letting devs create pageObjects manually, and inject the session into the pageObjects, we should think about decorating the Mink session, and letting it create the correct pageObjects based on the current url?

Just my 2c