page object model as mvc analogy

[David]

I was just wondering how one describes page object model (POM) to a non-Selenium/QA person like a developer besides talking about making your tests object oriented around pages and tests. Perhaps Model-View-Controller (MVC) could be another way, for which devs may be well familiar with.

I'm fairly novice to MVC as I'm not really a Dev, but this is what I thought in terms of mapping POM to MVC:

Model ~ the test case(s) & test data inputs that invoke controller & has app/test flow logic & business rules (acceptance criteria) to assert against
Controller ~ the page objects that do the work
View ~ browser/client target being tested against that provide the rendered/processed output. also linked to model for what to expect in terms of business rules on output.

Your thoughts?

[Michael Wowro]

Hallo David,

very interesting thoughts!
For me the description of "model" and "controller" matches the analogy. For "view" I'm not quite sure - can you precise? Do you mean the browser or the webpage? In my imagination we (the functional testers) look to the webpage from the opposite perspective then the developers. I think with the developers we share the same "view" but from 180 degrees turned perspective (and with different accent)
Hope that thread will be active ...

Yours Michael

[David]

Glad you find my discussion interesting Michael. I do hope to get more feedback from others as well.

Yea, I wasn't sure what to map the view to for POM. I was trying to define with what I know and the wikipedia definition of MVC

http://en.wikipedia.org/wiki/Model–view–controller

it could be the browser, the webpages rendered by the browser, or the WebDriver and the its settings that are used (e.g. FirefoxDriver with FFProfile vs IEDriver, etc.) Or perhaps the view is also part of the model in some way, not sure how it differs.

[Nikolay Georgievskiy]

Yes that's slightly correct analogy. I also thought about it. I found the problem in that analogy that people call MVC very different things which sometimes works in very different way. The more mess can be created by calling MVC the thing which isn't mvc at all.
So I think it's better just to design your desired testing framework architecture using some universal instruments (e.g. uml) and present it to developers who can understand it. If developers / automation_test_analysts can't understand that then analogies with mvc wouldn't help neither.

[Samantha]

I describe Page Objects as a parallel to a Data Access Layer (DAL) that one might use when constructing a database application.  DALs are a wrapper that encapsulates all interaction with the database. PageObjects are a wrapper that encapsulates all interactions with a web page.

Most of concepts apply.

It's a bad practice to tightly couple your application or bury business logic in your DAL. It's a bad practice to put test logic in your pageobjects.

That is the way that I describe it.

[Michael Wowro]

@Nikolay:
can you please tell, what the common missunderstandings are about mvc - I'm really tense.
can you please post such a UML - I'm even more tense ...

@Samantha:
until now I have known DAL only as an indian dish - but I'll keep that second analogy in mind :)

Yours Michael

[Nikolay Georgievskiy]

The first answer's lost :(
I'm sorry for not having time to relax all you tenses.

Not every architecture with 3 layers is MVC. Original MVC doesn't have separation of view layer between client and server so many web frameworks implement something similar to original MVC but in different ways.

Giving such an approximate description of what you are coding to developers you take a risk of all of them continue coding different things.