Home

Автор: Баз Дийкстра (Bas Dijkstra)

Оригинал статьи: http://www.ontestautomation.com/choose-wisely/

Перевод: Ольга Алифанова

В своей недавней статье, опубликованной на TechBeacon, я утверждал, что тесты на уровне API копают золотую жилу скорости выполнения, стабильности (как стабильности запуска, так и стабильности требуемой поддержки) и тестового покрытия. Однако я забыл упомянуть, что именно сподвигло меня написать такую статью. Об этом я и расскажу.

На самом деле причина для такой темы у меня была только одна: я слишком часто вижу, как все идет наперекосяк, когда люди начинают писать автотесты. Сейчас я работаю с несколькими клиентами над двумя разными проектами, и их объединяет стремление к end-to-end тестам (зачастую при помощи инструментов вроде Selenium или Protractor), с проверками, которые выходят за рамки юнит-тестов.

Вот вам пример. Я работаю над проектом, в котором мы собираемся создать автоматические проверки для веб-магазина, который продает электронные сигареты и аксессуары для них в Соединенных Штатах Америки. В магазине несколько продуктовых категорий, возрастных групп покупателей (некоторые продукты можно приобретать, если вам больше 18, некоторые – если вам больше 21, некоторые продукты не учитывают возраст, и так далее). К тому же это США – 50 разных штатов, и в каждом свои правила и законодательство. Короче говоря, возможных комбинаций тут куча (я не считал, но точно в районе сотен). К тому же из-за жестких правил США, и штрафов за нарушение этих правил, автотесты должны включать абсолютно все возможные комбинации.

Звучит логично, но проблема в том, что заказчик предлагает написать автоматизированный end-to-end тест для каждой из возможных комбинаций. Следовательно, нам нужно создать заказ для каждой комбинации продуктовой группы, возрастной группы и штата, и каждый заказ включает заполнение трех или четырех разных форм и несколько переходов по страницам. Другими словами, такой тест будет медленно запускаться (счет пойдет на часы), и его будет тяжело поддерживать.

Вместо этого я использовал Fiddler, чтобы проанализировать, что на самом деле делает приложение, чтобы определить, может ли покупатель приобрести выбранный им продукт. Короче говоря, оно просто вызывало API, которое содержало бизнес-логику принятия подобного решения. Итак, вместо сотен интерфейсных тест-кейсов я предложил создать кейсы на уровне API, которые будут проверять конфигурацию бизнес-логики, и добросить несколько end-to-end тестов, чтобы убедиться, что пользователь действительно может успешно разместить заказ или получить сообщение об ошибке при попытке заказать недоступный по какой-то причине товар.

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

• Используйте end-to-end тесты только для того, чтобы убедиться, что пользователь приложения может выполнять определенные последовательности действий (например, разместить заказ и оплатить его).
• Посмотрите (или спросите того, кто знает), можно ли получить доступ к бизнес-логике за пределами пользовательского интерфейса и, следовательно, протестировать ее на более низком (API или юнит) уровне, улучшив стабильность и скорость запуска тестов.

Для тех, кто знаком с пирамидой тест-автоматизации, это может прозвучать как точная иллюстрация к ней. Так оно и есть. Однако в свете недавно прочитанных мною статей (например, вот этой от Джона Фергусона Смарта), я думаю, не стоит привязывать все и вся к этой пирамиде. Вместо этого, как говорит Джон, надо определить, ЧТО вы пытаетесь протестировать, а затем написать тесты на нужном уровне. Если это ведет к пирамидальной схеме, пусть будет так. Коническая форма – это хорошо. Мороженое тоже конической формы. Я люблю мороженое.

Несмотря на это небольшое лирическое отступление про пирамиду тест-автоматизации, я думаю, что вышеописанный случай хорошо иллюстрирует мою точку зрения. Как я уже говорил, создание наиболее эффективных автоматизированных тестов происходит так:

• Вначале определите, зачем вы автоматизируете эти тесты. Это выходит за рамки тематики моей статьи, но это первый вопрос, который вы должны себе задать. В примере из статьи ответ был простым – потому что риск и эффект от возможных штрафов были достаточно велики, чтобы оправдать автоматизированное тестирование.
• Затем решите, что вы будете тестировать. В данном случае это бизнес-логика, определяющая, можно или нет покупателю приобрести определенный товар в зависимости от штата проживания, идентификатора продукта и даты рождения.
• Наконец, мы возвращаемся к теме статьи – ответьте на вопрос, как тестировать отдельное приложение или компонент. В данном случае бизнес-логика – цель наших тестов – отражена на уровне API, поэтому имеет смысл писать тесты на этом уровне. Лично я не горю желанием писать сотни тестов на уровне интерфейса, а потом отслеживать их и поддерживать.

Я уверен, что в вашей ежедневной работе встречаются ситуации, когда пересмотр подхода к автотестам может принести вам ощутимую выгоду. Это может быть и не уход от UI к API (хотя это наиболее частое явление), это может быть также создание юнит-тестов вместо end-to-end UI тестов. В некоторых случаях это замена большого количества нерелевантных юнит-тестов на небольшой сьют более мощных интеграционных API-тестов. Возвращаясь к тому, о чем говорил Джон в своей статье на LinkedIn, вы необязательно должны придерживаться пирамиды автотестов – вы должны поступать так, как правильно именно для вашей ситуации. Может получиться и пирамида. А может и нет. Выбирайте (и автоматизируйте) с умом.

Обсудить статью на форуме