You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
PageObjectLibrary is a lightweight [Robot Framework] keyword library that makes it possible to use the page object pattern when testing web pages with the keyword based approach of robot framework.
In the github repository is a small demonstration suite that includes a self-contained webserver and web site.
22
+
23
+
For the demo to run you must have robotframework 2.9+ and Selenium2Library installed. You must also have cloned the github repository to have access to the demo files.
24
+
25
+
To run the demo, clone the github repository, cd to the folder that contains this file, and then run the following command: :
26
+
27
+
```bash
28
+
robot -d demo/results demo
29
+
```
30
+
### A simple tutorial
31
+
32
+
For a simple tutorial, see <https://github.com/boakley/robotframework-pageobjectlibrary/wiki/Tutorial>
33
+
34
+
## How it works
35
+
36
+
The page object library is quite simple. Page object classes are implemented as standard robot keyword libraries, and relies on robot frameworks built-in [Set library search order keyword].
37
+
38
+
The core concept is that when you use PageObjectLibrary keywords to go to a page or assert you are on a specific page, the keyword will automatically load the library for that page and put it at the front of the library search order, guaranteeing that the page object keywords are available to your test case.
39
+
40
+
## Why page objects makes writing tests easier
41
+
42
+
The purpose of the page object pattern is to encapsulate the knowledge of how a web page is constructed into an object. Your test uses the object as an interface to the application, isolating your test cases from the details of the implementation of a page.
43
+
44
+
With page objects, developers are free to modify web pages as much as they want, and the only thing they need to do to keep existing tests from failing is to update the page object class. Because test cases aren’t directly tied to the implementation, they become more stable and more resistent to change as the website matures.
45
+
46
+
## A typical test without page objects
47
+
48
+
With traditional testing using Selenium, a simple login test might look something like the following: (using the pipe-separated format for clarity):
49
+
50
+
```robotframework
51
+
*** Test Cases ***
52
+
| Login with valid credentials
53
+
| | Go to | ${ROOT}/Login.html
54
+
| | Wait for page to contain | id=id_username
55
+
| | Input text | id=id_username | ${USERNAME}
56
+
| | Input text | id=id_password | ${PASSWORD}
57
+
| | Click button | id=id_form_submit
58
+
| | Wait for page to contain | Your Dashboard
59
+
| | Location should be | ${ROOT}/dashboard.html
60
+
```
61
+
62
+
Notice how this test is tightly coupled to the implementation of the page. It has to know that the input field has an id of “id_username”, and the password field has an id of “id_password”. It also has to know the URL of the page being tested.
63
+
64
+
Of course, you can put those hard-coded values into variables and import them from a resource file or environment variables, which makes it easier to update tests when locators change. However, there’s still the overhead of additional keywords that are often required to make a test robust, such as waiting for a page to be reloaded. The provided PageObject superclass handles some of those details for you.
65
+
66
+
## The same test, using page objects
67
+
68
+
Using page objects, the same test could be written like this:
69
+
70
+
```robotframework
71
+
*** Test Cases ***
72
+
| Login with valid credentials
73
+
| | Go to page | LoginPage
74
+
| | Login as a normal user
75
+
| | The current page should be | DashboardPage
76
+
```
77
+
78
+
Notice how there are no URLs or element locators in the test whatsoever, and that we’ve been able to eliminate some keywords that typically are necessary for selenium to work but which aren’t part of the test logic *per se*. What we end up with is test case that is nearly indistinguishable from typical acceptance criteria of an agile story.
79
+
80
+
## Writing a Page Object class
81
+
82
+
Page objects are simple python classes that inherit from `PageObjectLibrary.PageObject`. There are only a couple of requirements for the class:
83
+
84
+
- The class should define a variable named PAGE\_TITLE
85
+
- The class should define a variable named PAGE\_URL which is a URI relative to the site root.
86
+
87
+
By inheriting from `PageObjectLibrary.PageObject`, methods have access to the folloing special object attributes:
88
+
89
+
-`self.se2lib` - a reference to an instance of Selenium2Library. With this you can call any of the Selenium2Library keywords via their python method names (eg: self.se2lib.input\_text)
90
+
-`self.browser` - a reference to the webdriver object created when a browser was opened by Selenium2Library. With this you can bypass Selenium2Library and directly call all of the functions provided by the core selenium library.
91
+
-`self.locator` - a wrapper around the `_locators` dictionary of the page. This dictionary can contain all of the locators used by the page object keywords. `self.locators` adds the ability to access the locators with dot notation rather than the slightly more verbose dictionary syntax (eg: `self.locator.username` vs `self._locators["username"]`.
92
+
93
+
## An example page object
94
+
95
+
A page object representing a login page might look like this:
96
+
97
+
```python
98
+
from PageObjectLibrary import PageObject
99
+
100
+
classLoginPage(PageObject):
101
+
PAGE_TITLE="Login - PageObjectLibrary Demo"
102
+
PAGE_URL="/login.html"
103
+
104
+
_locators = {
105
+
"username": "id=id_username",
106
+
"password": "id=id_password",
107
+
"submit_button": "id=id_submit",
108
+
}
109
+
110
+
defenter_username(self, username):
111
+
"""Enter the given string into the username field"""
0 commit comments