Question

在Web集成测试中，由于某些操作，页面对象应返回其他页面对象。例如，LoginForm.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上很好地描述了in this question。

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

Answer 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})

作为单个操作的结果链接页面对象或多个可能的页面对象

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

1 个答案: