Unit-тестирование

ru-RU | создано: 25.01.2020 | опубликовано: 25.01.2020 | обновлено: 25.01.2020 | просмотров за всё время: 84

В концепции "Плохо", "Хорошо" и "Правильно"

Плохо если…

  • Я не могу писать unit-тесты.
  • Я не могу написать тест, потому что метод является статичным, или не возвращает результат, или приватный (static/void/private).
  • Мои тесты выполняются слишком долго.
  • Мои тесты не проходят если база данных, или web-сервис, или другая система (database/web-service/system) выключены или не доступны.

Хорошо если…

  • Unit-тесты выполняются быстро (fast).
  • Unit-тесты изолированы от каких-либо внешних зависимостей (isolated).
  • Unit-тесты легко повторяются (repeatable).
  • Unit-тесты должны быть сами себя контролировать (self-checking).
  • Unit-тесты должны быть «уместными», то есть не  должны требовать много времени на поддержку работоспособности (timely).

Правильно

Если писать тесты:

  • Ваш код будет покрыт «проверочным кодом».
  • Вы будете знать как писать код «правильно», то есть код будет менее связанным.
  • Вы упростите интеграцию нового функционала.
  • Вы защищены от регрессии при написания кода.
  • У вас появится дополнительная защита при публикации (CI/DC).
  • Сокращается время на функциональное тестирование.
  • Ваша совесть будет чиста :)

Если писать правильные тесты:

  • Именование тестов: 1) имя тестируемого метода; 2) сценарий в котором выполняется тестирование; 3) ожидаемое поведение при вызове сценария
  • Arrange, Act, Assert: Меньше путаницы
  • Минимализм при написание тестов – признак мастерства: 1) тесты более устойчивы к изменениям; 2) ближе к тестированию поведения чем к реализации.
  • Именование переменных в тестах: упрощение понимания при чтении.