这是 driver 类,定义了基本的定位方法
这是 page 类,一个类代表一个页面,一个方法是一个控件
这是测试用例,构建一个 page 类对象,然后调用类的方法进行操作。
我自己看的话没发现什么问题,但是后面感觉一个页面我要用的控件多的话就有一大串方法,我想问下大家都是怎么设计 PO 模式的。
现在的 page object 都是封装业务逻辑了, 不再只封装元素了。 也就是比如你这个登录页面, 就有一个 login 方法, 你 case 是调用这个 login 方法, 并不直接跟元素交互。
完全不对,现在的 Page Object 模式不能单独使用了,而是和数据驱动型模式配合使用;PO 中不再放业务逻辑操作,只放页面元素定位信息,再封装一个业务操作类函数,测试用例就直接调用业务函数,组合用例就可以了。这样维护起来比较方便,实例化对象的时候也不用那么多,
现在的 page object 都是封装业务逻辑了, 不再只封装元素了。 也就是比如你这个登录页面, 就有一个 login 方法, 你 case 是调用这个 login 方法, 并不直接跟元素交互。
把元素定位和动作分开封装,PO 只维护对象,动作可以抽象出来和元素进行任意组合,一般的 WEB 页面也就是几十种动作类型
感觉这样封装太多层了,后期比较难维护,我比较赞同 1 楼的做法,在 login PO 里面封装 login 方法,业务脚本直接调用 login 方法
不知道我之前写的这个框架的思路是不是你想要的呢?但是这是用 java 写的。
https://gitee.com/xuwangcheng/MasterYI-UI-Test-Framework
有一个细节我认为不太好,显示等待放在 BasePage 中有些不太合适,毕竟不是每个元素的 timeout 都是可以特定为一个值
问一下 如果一个 page 要适配多种实例,但它的构造函数是要传入 driver 通过 PageFactory.initElements 去初始化的。这种情况是通过多态去实现的吗?
哦哦,那就等于是把我 case 里面对元素的操作都放进了 login 方法里,所以 case 就变成了直接调用类的方法就可以了
还有的是跨页面的业务流程的封装。 就是在 page 这一层上面还会有一层。 比如有一个比较长的业务流程是涉及到好几个页面的, 偏偏这个业务流程还非常常用, 很多 case 都要用。 所以就专门封装一个业务层。
大佬请教一下,我现在是修改成这样了,但是这三个控件我怎么做描述呢?就是怎么标识这三个控件的名称,我就一行代码定位再操作的话之后容易忘了这个控件是干嘛用的了。我现在想的是把结果付给一个能描述控件的变量,但是感觉这个变量付了值也没有用。另一个方法就是不付变量,直接每个定位和操作都加一行描述控件的注释。大佬觉得怎么做合适点呢?
其实最好你搜索控件的时候,用 id, name 或者 className 这种一看就知道是什么的方式定位。 但如果你们研发根本不写 id, name 这些属性的话, 那就只能用注释了. 或者你写个简单易懂的变量名