{"_id":"54c51eb5d4928c0d00d98e51","githubsync":"","project":"54c51c5e2418480d0028a2c0","version":{"_id":"54c51c5e2418480d0028a2c3","__v":4,"project":"54c51c5e2418480d0028a2c0","createdAt":"2015-01-25T16:39:58.382Z","releaseDate":"2015-01-25T16:39:58.382Z","categories":["54c51c5e2418480d0028a2c4","54c51da3796aed0d009fc80f","54c51db22418480d0028a2c9","54c51dbd1613c70d00eeacbe"],"is_deprecated":false,"is_hidden":false,"is_beta":false,"is_stable":true,"codename":"","version_clean":"1.0.0","version":"1.0"},"category":{"_id":"54c51da3796aed0d009fc80f","version":"54c51c5e2418480d0028a2c3","__v":2,"pages":["54c51eb5d4928c0d00d98e51","54c51f062418480d0028a2d2"],"project":"54c51c5e2418480d0028a2c0","sync":{"url":"","isSync":false},"reference":false,"createdAt":"2015-01-25T16:45:23.147Z","from_sync":false,"order":0,"slug":"introduction","title":"Introduction"},"__v":1,"user":"54c4b05742190d0d00f5fbde","updates":[],"next":{"pages":[],"description":""},"createdAt":"2015-01-25T16:49:57.959Z","link_external":false,"link_url":"","sync_unique":"","hidden":false,"api":{"results":{"codes":[]},"settings":"","auth":"required","params":[],"url":""},"isReference":false,"order":0,"body":"Seleno helps you to write automated UI tests in the right way by implementing Page Objects and Page Components and by reading and writing web page data using strongly typed view models. It uses Selenium Web Driver for browser automation.\n\n## Page Objects\n\n### What are Page Objects?\nThe Page Object design pattern is a way of encapsulating the interaction with an individual page in your application in a single object. It makes heavy use of OO principles to enable code reuse and improve maintenance. Rather than having tests that are a series of Selenium commands that are sent to the server, your tests become a series of interactions with objects that represent a page (or part of one).\n\n### How does it work?\nThe usage of the Page Object design pattern creates a strong separation of concerns between tests and Page Objects. The tests specify ***what*** should happen and the Page Objects encapsulate ***how*** it happens. \n* Tests are very procedural. They only interact with the Page Objects and make assertions. They should not have any implementation details, such as Selenium calls, whatsoever. \n* Page Objects encapsulate all of the interaction with Selenium, and all of the logic of that interaction. There are no test assertions in the Page Objects but they can throw exceptions.\n\n### What are the benefits of using Page Objects?\n* Separating test specification from test implementation makes tests more robust. If you change how a feature works, you just have to change the Page Object, rather than every test that uses the feature.\n* Maintenance is easier because you only have to change things in one place.\n* Tests are more readable as they just work with Page Objects and make assertions. They do not have any Selenium code as this is hidden away in the Page Object.","excerpt":"","slug":"introduction-to-seleno","type":"basic","title":"Introduction to Seleno"}

Configuration

Page Objects

Introduction to Seleno

Seleno helps you to write automated UI tests in the right way by implementing Page Objects and Page Components and by reading and writing web page data using strongly typed view models. It uses Selenium Web Driver for browser automation.
## Page Objects
### What are Page Objects?
The Page Object design pattern is a way of encapsulating the interaction with an individual page in your application in a single object. It makes heavy use of OO principles to enable code reuse and improve maintenance. Rather than having tests that are a series of Selenium commands that are sent to the server, your tests become a series of interactions with objects that represent a page (or part of one).
### How does it work?
The usage of the Page Object design pattern creates a strong separation of concerns between tests and Page Objects. The tests specify ***what*** should happen and the Page Objects encapsulate ***how*** it happens.
* Tests are very procedural. They only interact with the Page Objects and make assertions. They should not have any implementation details, such as Selenium calls, whatsoever.
* Page Objects encapsulate all of the interaction with Selenium, and all of the logic of that interaction. There are no test assertions in the Page Objects but they can throw exceptions.
### What are the benefits of using Page Objects?
* Separating test specification from test implementation makes tests more robust. If you change how a feature works, you just have to change the Page Object, rather than every test that uses the feature.
* Maintenance is easier because you only have to change things in one place.
* Tests are more readable as they just work with Page Objects and make assertions. They do not have any Selenium code as this is hidden away in the Page Object.