Итак, какие типы тестов нам нужны?
Чтобы ответить на этот вопрос, нам нужно сначала задать другой вопрос; «Какие обещания дает наш продукт?», что вызывает еще больше вопросов:
- Какие платформы официально поддерживаются?
- Каковы минимальные системные требования?
- Какой уровень WCAG будет поддерживаться?
- Гарантирует ли это соответствие любым ожиданиям в отношении производительности? (Например: время запуска, время безотказной работы, обработка определенного количества запросов или выполнение задачи в определенное время и т. д.)
- Гарантирует ли это резервное копирование/восстановление любого состояния?
- Гарантирует ли это безопасность/защиту любого типа данных?
- Гарантирует ли это обратную совместимость?
- Гарантирует ли это определенный уровень безопасности?
- Можно ли его установить/удалить/обновить?
- Нужны ли ему определенные разрешения для работы?
- Поддерживает ли он i18n и l10n?
Это лишь некоторые вопросы, которые я могу задать на данный момент. Вы можете увеличить их.
Для каждого типа обещаний требуется своя стратегия тестирования. Итак, как вы можете легко заметить, ответить на вопрос, какие типы тестов нам нужны, непросто. С другой стороны, мы не обязаны отвечать на все эти вопросы или не обязаны оправдывать ожидания, которые мы не обещали. Единственное, что имеет значение, это то, что мы официально обещали предоставить.
Помните:
Несмотря на то, что определить, какие типы тестов нам нужны, непросто, есть 4 типа тестирования, которые распространены почти в каждом проекте.
- Статический анализ
- Модульные тесты
- Интеграционные тесты
- Функциональные тесты
Статический анализ позволяет поддерживать качество кода продукта. Модульные, интеграционные, функциональные тесты предотвращают выпуск незапланированных/непреднамеренных критических изменений, и все хотели бы избежать этого любой ценой. Вот почему эти 4 типа оказались наиболее распространенными типами тестирования.
Статический анализ
В настоящее время я также работаю над другой серией статей о статическом анализе. Итак, я не буду вдаваться в подробности здесь. А пока я хочу поделиться с вами одной историей.
Жил-был великий врач, который мог вылечить практически любую болезнь. Он был так хорош в том, что делал, что его имя распространилось за пределы его страны.
Однажды путешественник слышит его имя и хочет с ним встретиться. Прибыв в деревню доктора, он узнает, что у доктора есть два старших брата, которые тоже были врачами, но путешественник никогда о них не слышал.
Он становится еще более любопытным и спрашивает доктора: «Ты самый младший из своих братьев и сестер, но ты лучший из них. Как ты так превзошел своих братьев?».
Молодой доктор спокойно улыбается: «Переплюнуть их? Нет, на самом деле они оба лучшие врачи, чем я. Я лечу только общие проблемы, с которыми каждый может столкнуться в своей повседневной жизни. Так что я просто самый посещаемый и самый известный. Мой старший брат спасает пациентов с редчайшими заболеваниями. Поэтому очень немногие знают его навыки. А мой старший брат вообще не дает людям заболеть. Таким образом, никто не знает его имени.
Я думаю, что инструменты статического анализа напоминают самого старшего брата в этой истории. На самом деле они решают проблемы до того, как они возникнут, просто помогая вам следовать передовым методам кодирования и соблюдать согласованные соглашения о кодировании для ваших продуктов, но мы не тратим достаточно времени на статический анализ. Вот почему я бы посоветовал вам уделить этому шагу немного больше внимания, если вы не делали его до сих пор. Вы можете начать отсюда: Awesome Eslint, SonarQube и Code Climate.
Функциональные тесты
Я хотел бы следовать необычному порядку и начать говорить о функциональных тестах перед интеграционными и модульными тестами. Потому что я думаю, что это единственный тип тестов, который может дать вам полную уверенность при выпуске вашего продукта.
Прежде чем идти дальше, давайте зададимся вопросом, зачем нам нужны функциональные тесты, и предположим, что вы написали модульные и интеграционные тесты только для тестирования своего продукта. Давайте зададим волшебный вопрос: Что может пойти не так?
Обычно модульные и интеграционные тесты выполняются на одной платформе. Таким образом, мы не знаем, что может случиться с другими поддерживаемыми платформами. Например, что-то, что работает в Chrome, может не работать в Firefox, или определенный API NodeJS, который мы используем с NodeJS v8.x, может быть объявлен устаревшим в NodeJS v12.x.
Другими словами, функциональные тесты — это интеграционные тесты, чтобы проверить, ведет ли себя продукт на целевых платформах так, как ожидается.
В идеале при функциональных тестах каждый продукт должен быть протестирован в производственной среде на всехофициальноподдерживаемых платформах. Это означает, что если продукт представляет собой веб-приложение, нам нужно протестировать его во всех поддерживаемых браузерах, а если это мобильное приложение, возможно, на всех устройствах, которые мы поддерживаем. Если это серверное приложение или коннектор ввода-вывода, нам нужно протестировать его со всеми поддерживаемыми версиями узла и операционными системами.
Также при написании функциональных тестов продукт следует использовать так, как он будет использоваться в продакшене. Это означает, что в продукте не должно быть заплаток, заглушек или насмешек. Любое поведение, связанное с тестами, может и должно быть задано с помощью переменных среды, и в идеале это должно изменять только незначительные вещи, такие как уровень ведения журнала.
Функциональные тесты должны охватывать всекритерии приемлемости продукта. Это означает, что все, что мы обещали предоставить, должно быть протестировано с помощью функциональных тестов.
Функциональные тесты должны быть написаны только с использованием общедоступного интерфейса продукта. Если функциональное тестирование зависит от определенного глобального или внутреннего состояния, в идеале у продукта должен быть общедоступный API, который позволяет нам настроить продукт для достижения желаемого состояния.
Однако, если это не так, у нас могут быть служебные функции для создания желаемого глобального состояния (создание записей базы данных, файлов конфигурации или данных, установка даты и т. д.) . Таким образом, когда мы запускаем продукт, желаемое внутреннее состояние может быть создано автоматически с использованием глобального состояния и входных данных, поступающих из общедоступного интерфейса.
Функциональные тесты (не всегда, но часто) основаны на сценариях. Это означает, что если в вашем продукте есть определенное действие, которое можно вызвать только после другого действия, вам может потребоваться протестировать каждый шаг отдельно.
Итак, подводя итог, давайте предположим, что мы последовали всем приведенным выше советам и написали функциональные тесты, которые охватывают все возможные сценарии, которые могут произойти с нашим продуктом на всех поддерживаемых платформах. Что может пойти не так?
Вам пришлось бы ждатьмногои это стоило бымного. С точки зрения публикации продукта без ошибок, при таком подходе ничего не могло пойти не так. У вас всегда будет стопроцентная уверенность, поскольку вы охватили буквально все.
Однако для запуска этих тестов вам потребуется несколько серверов и зависимостей (база данных, почтовые серверы, веб-службы и т. д.), которые будут дорогостоящими, а поскольку тесты имеют состояние, вам нужно будет дождаться выполнения всех соответствующих шагов. Это время также имеет стоимость.
На этапе разработки нам нужен быстрый и дешевый механизм обратной связи, чтобы как можно быстрее обнаруживать потенциальные проблемы.
Да, теперь круг замкнулся. Я говорю об модульных и интеграционных тестах.
Однако это расплывчатые термины, и ни у кого нет стандартного подхода к их написанию. В этой серии статей моя главная цель — разрешить эту двусмысленность.
У меня есть мечта, мечта, в которой мы можем разделить модульные тесты и интеграционные тесты настолько отчетливои четко, что даже младший разработчик или новый разработчик в команде может сказать, что нужно тестировать и как его тестировать. Мечта, в которой модульные и интеграционные тесты вместе могут заменитьфункциональные тесты.
Часть 3 — Действительно ли необходимо тестирование?
Часть 4 — Итак, какие типы тестов нам нужны? (Сейчас читаю)
