Vitalii Tsybulnyk / Виталий Цыбульник

On Software Development / О софтверной разработке

About the author

    Vitalii Tsybulnyk
Vitalii Tsybulnyk is a Software Engineering Manager at Mictosoft Azure.
E-mail me Send mail

Activity

Recent comments

Disclaimer

The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.

© Copyright 2008-2018

Основы юнит-тестирования

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

Итак, хорошие юнит тесты:

  • Автоматизированы
  • Выполняются быстро: выполнение сотни или даже тысячи юнит-тестов должно занимать считанные секунды
  • Написаны в рамках эффективного фреймворка
  • Независимыми друг от друга
  • Результат работы теста воспроизводим и повторяем
  • Легко поддаются отладке
  • Написаны автором кода
  • Оставляют конфигурацию / окружение в неизменном состоянии
  • Имеют высокое покрытие кода (code coverage): при создании юнит-теста важно выполнить каждую строчку тестируемого кода и убедиться что все возможные условия протестированы.
  • Поддаются хранению и сопровождению
  • Тестируют как функциональность, так и аварийные ситуации: т.н. "позитивные" тесты подтверждают, что метод работает корректно в ожидаемых условиях, а "негативные" тесты проверяют что метод корректно обрабатывает нержиданные или критические условия
  • Покрывают граничные значения входных параметров: посхольку дефекты часто имеют место на границах, хоршей стратегией есть покрытие значений немного не доходящих до граничных, равных граничным, и немного превосходящих граничные.

Юнит-тесты имеют и некоторые органичения, о которых тоже нужно помнить:

  • Юнит-тестирование не находит все ошибки в коде: оно показывает только наличие ошибок, а не их отсутствие
  • У юнит-тестирования ограниченные рамки: это тестирование «белого ящика»
  • Юнит-тестирование не покрывает сценарии и интеграцию между компонентами

Одной из наиболее важных техник, которые позволяют создать хорошие юнит-тесты, является техника использование mock-объектов (mock objects). Mock-объект - это симуляция реального объекта там, где использование реального объекта невозможно или нарушает принципы юнит-тестирования, например когда реальный объект:

  • предоставляет недетерминированные результаты (например текущее время или температуру)
  • имеет трудно воспроизводимые состояния (например ошибка сети)
  • медленный (например полная база данных или файл на диске)
  • ещё не существует или может изменить поведение
  • должен содержать информацию или методы, необходимые только для тестирования

Categories: Development
Posted by Vitalii Tsybulnyk on Friday, August 21, 2009 1:57 PM
Permalink | Comments (0) | Post RSSRSS comment feed

Add comment




  Country flag

b i u quote
Loading