Тестирование программного обеспечения перед его выпуском имеет важное значение.

В идеале мы хотим провести как можно больше тестов. Если у нас будет больше уверенности в том, что наши изменения в коде ничего не сломают, мы сможем позволить себе двигаться быстрее.

Есть много способов, которыми мы можем тестировать программное обеспечение. Четыре основных типа тестов (перечислены в алфавитном порядке):

  • Концы с концами.
  • Интеграция.
  • Руководство.
  • Единица.

Я работал в компании, где у нас было мало автоматизированного тестирования. Благодаря большим функциям, длительному времени разработки и (ручного) тестирования было сложно развернуть его за более короткие циклы. Когда мы обратились за внешним советом, мы получили рекомендацию добавить больше тестов в слоях.

  • Будьте щедры на модульные тесты. Добавляйте их в любые классы, где это имеет смысл. Они обеспечивают базовую проверку ввода/вывода.
  • Используйте интеграционные тесты для совместного тестирования нескольких компонентов. Обычно вам нужно меньше таких тестов, чем модульные тесты.
  • Сквозные тесты проверяют, что запросы к API могут быть успешно отправлены, а ответ соответствует ожиданиям.
  • Нереально, чтобы все тесты можно было автоматизировать. Некоторое ручное тестирование все еще будет необходимо.

Количество тестов каждого типа уменьшается в каждом слое.

Пирамида тестирования

На рисунке 1 показана пирамида тестирования. Модульные тесты составляют основу базового уровня и, как правило, являются наиболее многочисленными. По мере того, как мы движемся вверх, тесты становятся более ответственными:

  • Интеграционные тесты проверяют больше компонентов, чем модульные тесты.
  • Сквозные тесты проверяют больше, чем интеграционные тесты.

Написание программного обеспечения включает в себя как время разработки, так и время тестирования. Мы можем провести время тестирования одним из двух способов:

  • задним числом. Мы строим фичи как можно быстрее, без тестов. Дефекты будут обнаружены QA или (что еще хуже) клиентами. В конечном итоге мы потратим время на переключение контекста, чтобы исправить их. Если на этом этапе тесты не написаны, любые будущие изменения означают, что это может произойти снова. И опять. И опять.
  • Предварительно. Мы пишем тесты вместе с программным обеспечением. Это обеспечивает защиту от регрессий. Это не поймает все. Но это больше, чем ничего.

Краткое содержание

Разработка идет быстрее, когда вы уверены в своем коде. Тестирование обеспечивает эту уверенность. Как только тесты будут автоматизированы, часть этой уверенности может прийти без каких-либо дополнительных усилий с вашей стороны.

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

Но автоматизированные тесты не могут охватить все, и некоторое ручное тестирование все же потребуется.

Практически невозможно написать код на 100% без ошибок, особенно когда он становится сложным. Но у вас есть возможность что-то с этим сделать. Написав тесты вместе с кодом, вы можете получить почти мгновенную обратную связь, уменьшить количество ошибок и предотвратить регрессию. Может показаться, что вы двигаетесь медленнее, но это, скорее всего, сэкономит вам время и стресс в долгосрочной перспективе.

Первоначально опубликовано на https://webdeveloperdiary.substack.com.