Связывание объектов страницы или нескольких возможных объектов страницы в результате одного действия

Question

В тестировании веб-интеграции ожидается, что объекты страницы будут возвращать другие объекты страницы в результате некоторых действий. Например, LoginForm.submit() может вернуться CustomerDashboard объект страницы в случае успеха или LoginFailed объект на провал.

Мне трудно понять, что происходит, когда система не настолько детерминирована. Например Order.submit() может привести к OrderProcessing страница или OrderProcessed стр. Какой лучший способ справиться с таким сценарием? Должен Order.submit() вернуть набор возможных объектов PageObject, которые затем обрабатываются в отдельном тесте? Какой рекомендуемый подход здесь?

Обновление с расширенной формулировкой проблемы

Представьте, что у вас есть система покупок, которая принимает заказы. При отправке заказа система может обработать заказ немедленно или заказ может быть помещен в очередь. В конце концов, заказ в очереди обрабатывается. В 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 метод. В данном конкретном случае меня не очень интересует состояние "в очереди". Я хочу добраться до точки обработки заказа, чтобы я мог проверить различные свойства заказа.

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