Тестируемость - одно из главных критериев нашего кода. Написание хорошего тестируемого кода делает продукт более стабильным.

Неважно, любите вы TDD или ненавидите его, тесты всегда спасают нас. Для любого проекта, который претендует на звание серьезного, необходимо иметь покрытие для тестирования либо в конце проекта, либо в то же время.

Я знаю, что модульное тестирование - это тема для червяков. Однако есть много пробелов и уловок, которые многие разработчики упускают (как и я), в том числе:

  1. Общие техники
  2. Языковые уловки, которые делают код более тестируемым
  3. Инструменты для тестирования
  4. Различия между тестированием разных типов продуктов (фреймворков, приложений и т. Д.)

Итак, это первый пост из серии, посвященной большой теме тестирования. И я хочу рассказать вам, что я узнал в ходе тестирования, и некоторые подходы, которые действительно спасли мне жизнь. Если вы хотите узнать о языковых приемах в Swift, которые делают ваш код более тестируемым, и о многом другом, посетите John Sundell. Здесь мы поговорим о разных подходах к модульному тестированию.

Хорошо, приступим. Во-первых, вы должны запомнить несколько правил написания тестов, которые ДОЛЖНЫ быть реализованы.

  1. Изолируйте тесты друг от друга.
  2. Составьте небольшой тест-лист. В списке критических частей системы
  3. Напишите тест, начиная с конца. В TDD это называется «сначала утверждать».
  4. Сохраняйте тестовые данные в неявном виде
  5. Используйте очевидные тестовые данные

Итак, давайте посмотрим на каждого из них поближе.

Изолировать тесты друг от друга

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

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

Вот что вы получите от изолированных тестов:

  1. Чистые тесты
  2. Экономия времени на отладке
  3. Продуктивность

Помните, каждый раз, когда вы заставляете свой тест зависеть от чего-то вне его, вы делаете его хуже, а в какой-то момент даже бессмысленным.

Тест-лист

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

Вот что вы получите из списка тестов:

  1. Порог входа снижается
  2. Качество тестов
  3. Продуктивность

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

Начать тест с конца

Этот подход исходит из TDD (разработка через тестирование). О прибыли от TDD ведется много дискуссий. Но даже если вы сначала тестируете код, вы должны понимать, что ваш тест ожидает проверить. Таким образом, тест подскажет, что именно нужно сделать, чтобы пройти тест.

Вот что вы получите от написания тестов сверху вниз:

  1. Вы сразу же определяете свои ожидания
  2. Вы остаетесь сосредоточенными и находитесь в контексте задачи, а не плаваете в тестовом кейсе.

Сохраняйте тестовые данные в неявном виде

В наших тестах мы используем некоторые постоянные значения, например строка, числа или что-то еще. Но когда кто-то другой откроет ваш тест, его первым вопросом будет: «Почему используется строка« Тестовый набор »?». Итак, мы должны неявно обозначить, почему мы используем эти тестовые данные. Это можно получить из названия метода тестирования, объявления компонентов тестовых данных в другом месте и т. Д.

Вот что вы получите от неявных тестовых данных:

  1. Чистые тесты
  2. Понятный и читаемый контекст тестового примера и тестовых данных
  3. Не тратьте время на размышления о значении тестов

Очевидные данные испытаний

Иногда в тестах нахожу что-то такое: 100/2 * 36. Что это? Это почему? Почему именно это значение? Он вызывает много вопросов, и вместо того, чтобы читать тест и понимать назначение системы или класса, я трачу много времени, пытаясь понять сам тест. Это плохой способ писать тесты. Даже если вы напишете их для себя, в какой-то момент вы забудете контекст, и данные будут неправильно поняты создателем, поэтому рассчитывайте их на этапе написания тестов и не тратьте свое и чужое время.

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

Вот что вы получите из свидетельств данных испытаний:

  1. Значение
  2. Четкость бизнес-логики
  3. Уменьшает боль при чтении тестов :)

Издеваться над своими данными

Не копируйте части тестов, кроме создания объектов. Не копируйте и не вставляйте при кодировании, но при тестировании это не проблема. Вы тестируете создание объекта в одном тесте, вы тестируете использование объекта в другом тесте, и часть создания объекта может быть скопирована. Не пытайтесь чрезмерно оптимизировать, когда это не требуется.

Помните, что большие тесты не обязательно проверяют все случаи, а маленькие тесты вообще не охватывают случаи.

Это были некоторые технологии, которые можно было использовать для тестирования в Интернете, на компьютере или на мобильных устройствах. В следующий раз мы создадим тесты и применим эти подходы в реальной жизни.

Надежда кому-то помогла.

Удачи ;)