Page Object Patter For Functional Test

Why?
Functional test characteristic

1. The number of tests is mostly large.
2. Page structure and elements may be changed frequently.

If our tests interact directly with the test driver (selenium,etc).

1. UI element locators(Xpath, CSS, element Ids, names, etc) are copuled and repeat throughout the tests logic. It is hard to maintain, refactor and change especially when we change the page structure.
2. The fine-grained UI operations hide our actual test intention. After some time we can not easily to identify what we want to do before.

What?
A Page Object models the UI elements that your tests interact with as objects within the test code. It decouples the test logic from the fine-grained details of the UI page.

Test -> Page Object -> Test Driver

The driver is the actual executor of browser action, like click, select, type etc. The page object has knowledage of the HTML structure.


Advantages

1. When UI changes, only responding page object need to be changed. The tests logic will not be affected.
2. It makes our tests logic simpler and more readable. Since the tests logic can only focus on its test secinaro rather than the structure of HTML page. As an example, think of login function, it only needs username and password, then do login action. How these are implemented shouldn't matter to the test. We don't care about that it uses a button or link to login.
3. Complex interactions can be modeled as methods on the page object, which can be used in multiple times.

Best Practices

1. Public methods represent the services that the page offers
2. Try not to expose the internals of the page. Like OO programming, object just expose the behaviour and hide its internal details.
   
3. Generally don't make assertions, but it is better to do some kind of check to ensure the browser is actually on the page it should be. Since our following tests are all base on the assumption. It can be done by checking something simple like title.
4. Methods return other page object. This means that we can effectively model the user's journey through our application.
5. Don't need to represent the entire page. It can be just a tab or a navigation bar that your test interacts with.
6. Only one place knows the HTML structure of a particular page. UI changes, the fix need only be applied in one place.
7. Different results for the same action are modeled as different methods. Since the test knows the expected state.

 

posted on 2011-10-18 21:57 *** 閱讀(248) 評論(0)  編輯  收藏