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)  編輯  收藏


          只有注冊用戶登錄后才能發(fā)表評論。


          網(wǎng)站導(dǎo)航:
           
          <2011年10月>
          2526272829301
          2345678
          9101112131415
          16171819202122
          23242526272829
          303112345

          導(dǎo)航

          統(tǒng)計(jì)

          常用鏈接

          留言簿

          隨筆檔案

          搜索

          最新評論

          閱讀排行榜

          評論排行榜

          主站蜘蛛池模板: 攀枝花市| 土默特左旗| 大埔区| 丰都县| 通渭县| 兖州市| 调兵山市| 巫山县| 双城市| 绩溪县| 咸丰县| 绥江县| 曲麻莱县| 阿巴嘎旗| 铜山县| 交城县| 北京市| 焉耆| 香河县| 澜沧| 金阳县| 阜宁县| 曲周县| 田东县| 东山县| 三原县| 茶陵县| 日土县| 旌德县| 津市市| 武安市| 兴化市| 双牌县| 罗甸县| 裕民县| 南投县| 读书| 曲阜市| 福鼎市| 德州市| 建阳市|