Объектная модель страницы: почему бы не включать утверждения в методы страницы?

Первый постер. Я работаю в сфере автоматизации пользовательского интерфейса уже много лет, но только недавно познакомился/получил инструкции по работе с объектной моделью страницы.Большая часть из них основана на здравом смысле и включает в себя методы, которые я уже использовал, но есть один тонкий момент, который я не смог обосновать в своем собственном уме, несмотря на активные поиски аргументированного объяснения. Я надеюсь, что кто-то здесь может просветить меня, поскольку этот вопрос вызвал некоторый ужас, когда я пытаюсь интегрировать POM с моими собственными лучшими практиками.

Из http://code.google.com/p/selenium/wiki/PageObjects:

Представленный выше код показывает важный момент: тесты, а не PageObjects должны нести ответственность за создание утверждений о состояние страницы... Конечно, как и в любом руководстве, есть исключения...

Из http://seleniumhq.org/docs/06_test_design_considerations.html#chapter06-reference:

Существует большая гибкость в том, как могут быть спроектированы объекты страницы, но есть несколько основных правил для получения желаемого ремонтопригодность вашего тестового кода. Сами объекты страницы должны никогда не делайте проверок или утверждений. Это часть вашего теста и всегда должен находиться в коде теста, а не в объекте страницы. Объект страницы будет содержать представление страницы, а услуги, предоставляемые страницей с помощью методов, но без кода, связанного с тем, что тестируемый должен находиться внутри объекта страницы.

Существует одна единственная проверка, которая может и должна объект страницы, чтобы убедиться, что страница и, возможно, важные элементы на странице загружались корректно. Этот проверка должна выполняться при создании экземпляра объекта страницы.

Оба эти «принципа» допускают возможные исключения, но я не могу не согласиться с основной предпосылкой. Я привык выполнять значительное количество проверок в «методах страницы», и я думаю, что наличие проверки — это мощная техника для поиска проблем в различных контекстах (т. е. проверка происходит каждый раз, когда вызывается метод), а чем только происходящее в ограниченном контексте конкретных тестов.

Например, давайте представим, что когда вы входите в свою AUT, появляется некоторый текст, который говорит: «Вы вошли в систему как ПОЛЬЗОВАТЕЛЬ». Уместно иметь один тест, специально подтверждающий это, но почему бы вам не захотеть проверять это каждый раз, когдавызывается login? Этот артефакт не имеет прямого отношения к тому, «правильно ли загружена» страница или нет, и он не связан с «что тестируется» в целом, поэтому, согласно приведенным выше рекомендациям POM, он явно НЕ ДОЛЖЕН быть в методе страницы. .. но мне кажется, что он явно ДОЛЖЕН быть там, чтобы максимизировать мощность автоматизации, проверяя важные артефакты как можно чаще, с как можно меньшим предусмотрительностью. Размещение кода проверки в методах страницы умножает возможности автоматизации, позволяя вам получать большое количество проверок «бесплатно», не беспокоясь об этом в своих тестах, и такая частая проверка в разных контекстах часто обнаруживает проблемы, которые вы НЕ обнаружили бы. если бы проверка была ограничена, скажем, одним тестом для этого артефакта.

Другими словами, я склонен проводить различие между проверкой, специфичной для теста, и «общей» проверкой, и я думаю, что последняя вполне уместна/желательна, чтобы последняя была широко включена в методы страницы. Это способствует более тонким тестам и более толстым объектам страницы,что обычно увеличиваетудобство сопровождения тестов за счет повторного использования большего количества кода, несмотря на противоположное утверждение в этих рекомендациях. Я упускаю суть? Каково реальное обоснование того, что НЕ требуется проверка в методах страницы? Является ли ситуация, которую я описал, фактически одним из «исключений», описанных в этих рекомендациях, и, следовательно, фактически НЕ несовместимым с POM? Заранее спасибо за ваши мысли. -jn-