Как стать автором
Обновить

Комментарии 6

Самый простой (хотя и точный) ответ – делайте любые тесты, дающие возможность оценивать классы и проектировать дальше. Но этот ответ плохо подходит для начинающих, поэтому придется углубиться в детали.

этот ответ вообще никому не подходит
У нас на Хабрахабре есть ли где-нибудь чья-нибудь блогозапись, простыми словами объясняющая разницу между модульными тестами (юнит-тестами), интеграционными тестами и приёмочными тестами?

А не то я призадумался и начал сомневаться в том, что всецело понимаю разницу.
Юнит-тесты.

Минимальные низкоуровневые тесты для проверки минимального блока кода (юнита), «оторванного от реальности». Это может быть функция, метод или маленький утилитарный класс. Можно сказать, что юнит-тесты проверяют принцип единой обязанности на уровне методов и мелких классов без зависимостей.
Признаки юнит-тестов:
  • Все значения в памяти
  • Нет обращений к инфраструктуре: нет потоков, нет файловой системы, нет БД
  • Сложные зависимости и инфраструктура мокаются


Интеграционные тесты

Более высокий уровень абстракции, чем юнит-тесты.
Тестирует функциональность системы (в частности класса) в связке с окружением и зависимостями. К тому же, тестируется взаимодействие составных частей (к примеру, последовательность состояний класса).
Признаки:
  • Тесты используют реальную инфрастуктуру: потоки, БД, файловую систему, зависимости системы
  • Тесты проверяют взаимодействие компонентов


Приемочные/функциональные тесты

Еще более высокий уровень абстракции, чем интеграционные тесты.
Тестируются фичи и их согласованность со спецификацией. По большей части провеярется то, что система производит нужный ответ на заданный ввод. При этом нас не интересует внутреннее состояние компонентов системы. Можно сказать, что система в приемочных тестах — черный ящик.
Признаки:
  • Тесты пишутся с точки зрения клиента системы
  • Тесты ориентированы на проверку ключевых требований, предъявляемых к конкретной фиче
  • Тесты проверяют соответствие ожиданий (спецификацию) и реальности


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

И да… Важный момент — инструментами тестирования надо владеть. Первое время нужно тупо тренироваться в написании тестов для своей предметной области… Можете вместе коллегами устроить соревнование на самый простой и красивый тест. Умение писать красивые тесты — это отдельный скилл…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории