要想同时解决这两个问题，可以引入Page Model模式（相信ThoughtWorks的人都会用）。上面的代码便可以写成这样：
|
it “Scenario: create story with full information” do create_story_page = @navigator.goto_add_story_page create_story_page.add_story :name=>’…’, :description=>’…’ …… view_story_page = page.save_and_view view_story_page.information.text.should contains(‘…’) …… end |
下面再来一个复杂点的测试用例：
|
it “Scenario: import all the stories from excel file” import_stories_page = @navigator.goto_import_stories_page import_stories_page.import_from excel_path preview_page = import_stories_page.preview_import preview_page.choose_import_stories :all preview_page.to_next_page preview_page.choose_import_stories :first story_list_page = preview_page.confirm_import story_list_page.stories.should contains(‘imported story1’) …… end |
看！代码是不是可读性很好，业务意图是不是很清晰。每一行代码都是一个业务操作，代表着测试用例的一个步骤，最后是一些断言，进行验收。断言也避免了 assertEquals这种写法，采用RSpec的should来达到可读性最佳，最贴近人类语言的效果。如果你仔细看看这段代码，会发现它没有一点 UI元素的操作在里面。UI再怎么重构，页面结构再怎么变化，测试用例代码都是稳定的。
因为Page Object封装了UI元素和结构，使得测试代码稳定，达到要修改只修改一处的效果。同时，Page Object也封装了业务行为及操作，使得测试代码更可读。Page Model还有几个重要的概念，Driver, Navigator, DataFixture，其实都是封装了不同的变化点，这里也不多做介绍。
验收测试的理想目标是全部自动化，测试代码即测试用例文档，易读易写。
推荐阅读：
