0

在 Web 集成测试中，页面对象预期会作为某些操作的结果返回其他页面对象。例如，aLoginForm.submit()可能在成功时返回CustomerDashboard页面对象或LoginFailed在失败时返回对象。

我难以理解的是当系统不是那么确定时会发生什么。例如Order.submit()可能会导致一个OrderProcessing页面，或者一个OrderProcessed页面。处理这种情况的最佳方法是什么？是否应该Order.submit()返回一个可能的 PageObjects 元组，然后在单个测试中处理？这里推荐的方法是什么？

使用扩展的问题陈述进行更新

想象一下，您有一个接受订单的购物系统。提交订单时，系统可能会立即处理订单，也可能会将订单放入队列中。最终，排队的订单得到处理。在 Rubyish 伪代码中，负责测试的页面对象对象是：

class ProcessedOrderPage < PageObject
    item order_id;
    item delivery_date;
end

class QueuedOrderPage < PageObject
    item orderInQueue;
end

class OrderPage < PageObject
    def submit_order_for_immediate_processing
        return ProcessedOrderPage.new
    end

    def submit_order_for_queued_processing
        return ProcessingOrderPage
    end
end

因此，在我们的测试中，我们可以执行以下操作：

processed_page = orderPage.submit_for_immediate_processing
assert_not_nil processed_page.order_id

或者我们可以测试其他场景：

queued_page = orderPage.submit_for_queued_processing
assert_not_nil queued_page.orderInQueue

这里的想法是我们确切地知道预期的行为，因此我们可以调用返回预期页面对象的帮助程序。事实上，这在这个关于 SO的问题中得到了很好的描述。

我正在尝试处理行为不是那么确定的情况。想象一下，上面submit_for_immediate_processing和 submit_for_queued_processing上面被折叠成一个方法，submit_for_processing并且行为是由系统的运行时属性决定的。也就是说，订单要么立即处理，要么放入队列中。从测试的角度来看，这种行为并不理想，但它就是这样。我想了解谁负责确定此submit_for_processing方法的结果。在这种特殊情况下，无论如何我对“排队”状态并不感兴趣。我想到达处理订单的地方，所以我可以验证各种订单属性。

4

1 回答 1

1

当前使用页面对象的最佳实践是使它们尽可能地分离，并避免链接。

如果您正在执行以下操作，则更容易查看测试中发生了什么：

visit(LoginPage).login
on(AccountPage).add_payment
expect(on(ConfirmationPage).success?).to eq true

相对：

expect(visit(LoginPage).login.add_payment.success?). to eq true

至于不确定状态问题，您可能需要遵循等待满足条件（已处理订单）的模式，以使测试与预期同步，然后继续。像这样的东西：

order_id = OrderPage.submit_order
wait_for_processed(order_id)
visit(ProcessedOrderPage, params={order_id: order_id})
于 2016-11-08T18:16:22.923 回答