Что тестировать, а не что такое тестирование — важный вопрос для всех команд. Тестирование — это средство достижения цели, и выбор приоритета тестирования различных частей вашей кодовой базы может оказаться трудным.
Лучший способ расставить приоритеты — исходя из вашей кодовой базы и целей вашей команды. Однако важно помнить, что, хотя для написания большого количества небольших тестов (в нижней части пирамиды тестирования, таких как модульные тесты) требуется мало времени и пропускной способности, которые имеют большое покрытие кода, они не обязательно уменьшают общее риск для вашего проекта.
Вы можете выбрать, что тестировать в первую очередь, подумав об основных вариантах использования вашего приложения, веб-сайта или библиотеки. Это может быть путем написания тестов компонентов для критических частей вашего сайта, основных компонентов, которые лежат в основе взаимодействия с пользователем. Например, разработчики сайта, который позволяет пользователям загружать данные временных рядов и управлять ими, должны представить и протестировать различные способы, которыми пользователь может выполнять эти задачи.
Другой подход к расстановке приоритетов предполагает получение как можно большего количества информации. Если у вас есть «опасная», устаревшая или плохо написанная несущая нагрузку часть вашей кодовой базы, над которой никто из вашей команды не любит работать, может быть полезно построить вокруг нее тесты, чтобы сделать ее поведение более согласованным, прежде чем игнорировать ее. его дальше или реорганизуйте его, чтобы исправить. Думайте об этом как о строительных лесах для здания, которое уже сдали, но в котором все еще находится ваш центр обработки данных.
Размерность
Мы ввели концепцию пирамиды тестирования или другой формы тестирования, но она, как правило, представляет только одно измерение тестирования: линию, идущую от небольших по объему простых модульных тестов к сложным, широкомасштабным тестам — модульным тестам и Интеграционные тесты и сквозные тесты.
Однако некоторые из длинного списка возможных типов тестов не отражают уровень сложности, а представляют собой цели или методы тестирования. Например, дымовые тесты — это другая категория тестов, которые сами по себе могут быть модульными, сквозными или другими тестами, но предназначены для того, чтобы дать тестировщикам полную уверенность в том, что тестируемый проект находится в допустимом состоянии. Визуальное тестирование также может быть полезно для небольшого компонента или для вашего сайта в целом.
Ваша кодовая база будет иметь уникальные требования. Например, в вашей кодовой базе может быть гораздо важнее согласовать одну функцию и написать разные типы тестов, чтобы убедиться, что она работает правильно. Новая функция, требующая тестирования, редко представляет собой отдельный компонент, функцию или подход , и ее влияние на ваш проект может быть широко распространено и в разных масштабах.
Ваши приоритеты тестирования также могут зависеть от потребностей вашего бизнеса. Высокотехнические системы могут потребовать сложного модульного тестирования для подтверждения правильности работы уникального алгоритма, тогда как высокоинтерактивные инструменты, скорее всего, будут сосредоточены на визуальном тестировании или сквозном тестировании, чтобы подтвердить, что сложные сенсорные вводы вызывают правильный ответ.
Ваш подход к тестированию
Постарайтесь сосредоточиться на тестировании вариантов использования вашей кодовой базы, независимо от их масштаба. Представьте, как пользователь может использовать любую часть вашего проекта — это может быть отдельный компонент, функция более низкого уровня или сквозной вариант использования высокого уровня. (Это также может выявить недостатки в ваших абстракциях в любом масштабе, если вы обнаружите, что ваш тест не может аккуратно взаимодействовать с тестируемым кодом.)
Важно, чтобы каждый тестовый пример имел четко определенную цель. Большие «всеобъемлющие» тесты могут быть громоздкими, как и ваш нетестовый код.
Немного о разработке через тестирование
Разработка через тестирование (TDD) — это уникальный подход к тестированию, ортогональный по масштабу или типам, поскольку он включает в себя написание тестов, которые должны провалиться, по крайней мере, на первых порах. Это может относиться как к ручному, так и к автоматическому тестированию: вы описываете цели, которых хотите достичь, выясняете, чего не хватает в вашем текущем решении или коде, и используете неудачный тест как руководство к решению.
Конечно, бесполезно тестировать все возможные сценарии в гипотетическом приложении или компоненте еще до того, как вы начнете его создавать. TDD имеет свое место, и он может быть полезен, когда ваша кодовая база становится более сложной.
TDD также является хорошей практикой при исправлении ошибок. Если вы сможете кодифицировать вариант воспроизведения ошибки, его можно будет включить в автоматизированный тест, который поначалу завершится неудачей. Когда вы исправите ошибку, тест будет пройден, что позволит вам определить, было ли исправление успешным, без подтверждения вручную.
Непрозрачная и прозрачная коробка
Это относится к тому, как вы тестируете любую часть вашей системы. Если он непрозрачен, вы не сможете заглянуть внутрь, например, при использовании открытого интерфейса класса вместо проверки его внутреннего устройства.
Если у вас нет особой причины не делать этого, лучше начать с тестирования непрозрачных коробок, чтобы вы могли разрабатывать тесты на основе того, как используются ваши компоненты, и не отвлекаться на то, как работают их внутренние компоненты. Если вы полагаетесь только на «публичный» интерфейс пути к коду (не обязательно общедоступный для ваших пользователей, но, возможно, для других частей вашего кода), вы можете провести рефакторинг и улучшить этот код, зная, что ваш тест обнаружит любые изменения.
Один из способов сделать ваш код «прозрачного ящика» более непрозрачным — это ввести настраиваемые элементы, такие как абстракции для зависимостей кода или обратные вызовы для наблюдения за состоянием, вместо того, чтобы это состояние было тесно связано с другими системами. Это делает ваш код более несвязанным и позволяет предоставлять «тестовые» версии. Альтернативно вы можете продемонстрировать, где ваш код взаимодействует с другими системами.