Home

Автор: Пол Гриззаффи (Paul Grizzaffi)
Оригинал статьи
Перевод: Ольга Алифанова

Недавно я слушал в Twitter про Page Object vs Screenplay. Это было интересное обсуждение, прозвучало много хороших точек зрения и идей. Затем я написал в Twitter, что эта сессия укрепила меня в убеждении, что автоматизированный стэк подходит для множества вариантов внедрения автоматизации. Стоит ознакомиться с сессией Spaces и тредом в Twitter.

Если вы достаточно углубитесь в тред, то увидите моего друга и коллегу Титуса Фортнера, который написал, что не понимает, как я разделяю поведения и действия. Затем он говорит о ряде нужд фреймворка. Прочитав это, я понял, что моя исходная статья упускала концепцию, о которой я говорю в своем докладе про стек автоматизации, и что мы по-разному используем терминологию. Я решил дополнить мою предыдущую статью на эту тему, чтобы восполнить пустоты.

Зачем говорить о стеке автоматизации, а не о фреймворке?

В ряде описаний фреймворков в треде Twitter я заметил упоминания «библиотеки ассертов» и «Rspec». Мой концептуальный набор не включает такие вещи; я сознательно оставляю их за бортом.

Почему я это делаю? В основном для портируемости. Хоть я и консультант, но большая часть моего взаимодействия с клиентами посвящена внедрениям (да, я все еще пишу код, и мне все еще это нравится). Я работаю с множеством клиентов в различных контекстах. Мне нужна модель, которая упрощает конкретное внедрение, но все еще направляет его структуру. Не описывая конкретные технологии, я получаю гибкость, позволяющую давать клиентам рекомендации, учитывающие их контекст. Не привязывая свой концептуальный стек к конкретному «тест-фреймворку» - скажем, NUnit, XUnit, или Rspec – я получаю свободу в отношении конкретики фреймворка и выбора подходящего языка программирования.

Помимо этого, полное отсутствие привязки стека к фреймворку, как минимум на его низших уровнях, дает возможность использовать его подходящие уровни для создания автоматизации, не основанной на тест-кейсах или тест-скриптах; я называю такой тип «нетрадиционной автоматизации» автоматизированной помощью. Я создал инструменты вроде «подачи заказов для электронной коммерции» и «рандомного кликера по ссылкам», которые помогают тестировщикам даже несмотря на то, что ни одна решаемая этими инструментами задача не может считаться «тест-кейсом» - как минимум, в традиционном понимании этого термина. Так как я независим от фреймворков – например, Rspec, MSTest, и т. д., я могу повторно использовать подходящие уровни стека, не привязываясь к возможностям этих фреймворков – и, возможно, не ограничиваясь ими.

С практической точки зрения определенная часть внедренного (в отличие от концептуального) фреймворка, как правило, привязана к тест-фреймворку. В целом мы не создаем опорные внедрения; мы стараемся быть полезными реальным людям, а привязка к определенной технологии часто бывает полезной. Откладывание этой привязки до момента внедрения дает внедрению стека повышенную портируемость. Ее можно дополнительно улучшить, внедряя привязку за прослойкой, фасадом, интерфейсом или другой подходящей функцией выбранного языка программирования.

Проясняем вопрос: действия и поведения

Дабы попытаться улучшить понимание разницы, которую я вкладываю в термины «действия» и «поведения», я хочу обратиться к тому, что я называю сердцем автоматизации – стимулу, ответу и проверкам. В концептуальном стеке уровень действий создает краеугольные камни для этой сердцевины:

• Найти то, с чем мы хотим взаимодействовать, если это необходимо.
• Создать стимул для этого (клик, ввод, POST, и т. д.)
• Получить ответ на этот стимул – это может потребовать ожидания.
• Выполнить одну или несколько проверок, ассертов и т. д. для этого ответа.

В этом концептуальном стеке этот уровень гранулярности – это уровень Действий: «найти», «стимулировать», «проверить» - это действие. Как упоминалось в исходной статье о стеке, работа на уровне действий может выглядеть так:

browser.LoginLink.Click()
browser.EmailAddressField.TypeKeys(“a@b.c”)
browser.PasswordField.TypeKeys(“p@ssw0rd”)
browser.LoginButton.Click()

или так:

HttpClient.GetAsync(requestUri).ConfigureAwait(continueOnCapturedContext: false);

Заметьте, что это довольно гранулярные действия для тест-автоматизации и программирования в целом. Так как автоматизация – это программирование, мы должны следовать соответствующим парадигмам программирования – таким, как инкапсуляция кода для повторного использования. И тут вступает в игру уровень Поведений.

Поведения – это доступные для повторного использования последовательности действий и других поведений. Если отталкиваться от предыдущего связанного с браузером примера, двумя возможными методами на уровне поведений могут быть:

void LogMeIn(string email, string pw)
{
    browser.EmailAddressField.TypeKeysemail);
    browser.PasswordField.TypeKeys(pw);
    browser.LoginLink.Click();
}
 
void GoToLoginPageAndLogMeIn(string email, string pw)
{
    browser.LoginLink.Click();
    LogMeIn(email, pw);
}

Заметьте, что в коде выше LogMeIn() использует возможности уровня действий; поведения создаются из доступных для повторного использования наборов действий. Также отметьте, что GoToLoginPageAndLogMeIn() как вызывает уровень действий, так и повторно использует уже определенное поведение. В целом мы применяем принципы базовой инкапсуляции и абстракции к коду тестов.

Повторюсь – этот стек автоматизации для меня концептуален. У меня есть доклад, объясняющий эту концепцию и приводящий реальные примеры ее применения, где она принесла пользу в различных контекстах приложения, а также использовалась для автоматизированной помощи. В большинстве моих реальных примеров внедрение стека отличалось, но уровни были или одинаковыми, или схожими. На разницу в уровнях влиял конкретный контекст организации – тестируемое приложение или «сырой» используемый инструмент. Контекст должен влиять на определение и внедрение каждого уровня стека. Некоторым организациям может понадобиться всего четыре уровня, а другим все семь. Если у каждого уровня есть значимая задача, и у стека есть разумное руководство, конкретная концепция стека может принести пользу в конкретном контексте. Стек, о котором я говорю, хорошо служит мне в разных контекстах, и может стать отличной отправной точкой для других команд.

Обсудить в форуме