有一段时间,我使用Page对象框架为我们的web应用程序编写了测试。但是一次又一次的测试,我注意到,我总是写同样的断言。
MyPage page = navigateToMyPage();
page.setField1("foo");
page.setField2("faa");
page = page.save();
assertThat(page.getField1(), is("foo));
assertThat(page.getField2(), is("aaa));所以我在考虑一个PageObjectValidator。
MyPage page = navigateToMyPage();
page.setField1("foo");
page.setField2("faa");
page = page.save();
page.validate(); // or Validator.validate(page)这样做的目的是集中一个页面的所有断言,不要在每个测试中重复它们(DRY),并且不要忘记一个断言。在场景后面,setField1(String)函数将其参数放在一个简单的POJO中,验证将遍历POJO的所有属性来执行断言(举一个简单的例子)。
你觉得这个主意怎么样?我无法在web上找到任何这样的例子,如果有人已经实现了这样的框架,请在这里提供您的输入。
发布于 2016-01-06 17:10:32
Martin 讨论是否应该在页面对象中包含断言:
对于页面对象是否应该包括断言本身,或者只是为测试脚本提供数据来执行断言,存在着不同的意见。主张在页面对象中包含断言的人说,这有助于避免测试脚本中断言的重复,使提供更好的错误消息变得更容易,并且支持更多的TellDontAsk风格的API。主张无断言页面对象的人说,包含断言将提供对页面数据的访问与断言逻辑混合在一起,并导致页面对象臃肿。我喜欢在页面对象中没有断言。我认为您可以通过为常见断言提供断言库来避免重复--这也可以使提供良好的诊断变得更容易。一种形式的断言是好的,即使是像我这样的人,他们通常赞成无断言风格。这些断言是在此时检查页面或应用程序不变量的断言,而不是测试正在探测的特定内容。页面对象通常用于测试,但不应该自己进行断言。他们的职责是提供对底层页面状态的访问。需要测试客户端来执行断言逻辑。
在此之后,如果您有相同的断言要在多个页面上重用,我将选择库。
public class PageValidator extends TypeSafeMatcher<AnyPage> {
public boolean matchesSafely(AnyPage page) {
return page.getField1().equals("foo") && page.getField2().equals("aaa");
}
public static PageValidator isValid() { return new PageValidator(); }
}您可以很容易地重用:
assertThat(myPage, isValid());否则,如果每个页面都有不同的不变量,我将定义一个接口。
public interface PageValidator {
boolean isValid();
}所有页面对象类都必须以其特定的方式实现。
发布于 2015-10-07 15:31:25
如果某些断言始终为真,则可以将它们放入pageobject中。但我发现,我的大部分断言取决于情况,测试有更多的知识,什么是真实的-因此,对我来说,更有意义的是,使大多数断言在测试。
如果经常从多个测试中重复某些断言,则可以将它们放入页面方法中,但在适当的情况下仍然从测试中调用它们。
发布于 2015-10-08 11:37:50
首先,你是在正确的方向思考,以达到模块化。我已经在我的项目中实现了这一点(类似于此)。你可以这样做:
public bool validate(object pageCalled)
{
try
{
assertThat(pageCalled.getField1(), is("foo"));
assertThat(pageCalled.getField2(), is("aaa"));
return true;
}
catch (Exception ex)
{
Console.WriteLine("FAIL : " + ex.Message);
return false;
}
}这样,如果所有断言都被传递,它将返回true,如果任何事情最终失败,异常将被捕获,false将被返回。
如果有效,请回复。
https://sqa.stackexchange.com/questions/15040
复制相似问题