Comments 6
Самый простой (хотя и точный) ответ – делайте любые тесты, дающие возможность оценивать классы и проектировать дальше. Но этот ответ плохо подходит для начинающих, поэтому придется углубиться в детали.
этот ответ вообще никому не подходит
У нас на Хабрахабре есть ли где-нибудь чья-нибудь блогозапись, простыми словами объясняющая разницу между модульными тестами (юнит-тестами), интеграционными тестами и приёмочными тестами?
А не то я призадумался и начал сомневаться в том, что всецело понимаю разницу.
А не то я призадумался и начал сомневаться в том, что всецело понимаю разницу.
Юнит-тесты.
Минимальные низкоуровневые тесты для проверки минимального блока кода (юнита), «оторванного от реальности». Это может быть функция, метод или маленький утилитарный класс. Можно сказать, что юнит-тесты проверяют принцип единой обязанности на уровне методов и мелких классов без зависимостей.
Признаки юнит-тестов:
Интеграционные тесты
Более высокий уровень абстракции, чем юнит-тесты.
Тестирует функциональность системы (в частности класса) в связке с окружением и зависимостями. К тому же, тестируется взаимодействие составных частей (к примеру, последовательность состояний класса).
Признаки:
Приемочные/функциональные тесты
Еще более высокий уровень абстракции, чем интеграционные тесты.
Тестируются фичи и их согласованность со спецификацией. По большей части провеярется то, что система производит нужный ответ на заданный ввод. При этом нас не интересует внутреннее состояние компонентов системы. Можно сказать, что система в приемочных тестах — черный ящик.
Признаки:
Итого: эти виды тестов не исключают друг друга. Они находятся на разных уровнях абстракции. Можно сказать, что юнит-тесты и интеграционные тесты делают проверки с точки зрения программиста, а функциональные тесты — с точки зрения клиента кода.
И да — бывают смешанные типы. К примеру, нам лень мокать зависимость от БД, но мы пишем «типа юнит-тест». В итоге получаем «интеграционный юнит-тест»(с минимальной зависимостью от БД) который в первую очередь проверяет поведение метода и в качестве стороннего эффекта — интеграцию этого поведения с БД.
Минимальные низкоуровневые тесты для проверки минимального блока кода (юнита), «оторванного от реальности». Это может быть функция, метод или маленький утилитарный класс. Можно сказать, что юнит-тесты проверяют принцип единой обязанности на уровне методов и мелких классов без зависимостей.
Признаки юнит-тестов:
- Все значения в памяти
- Нет обращений к инфраструктуре: нет потоков, нет файловой системы, нет БД
- Сложные зависимости и инфраструктура мокаются
Интеграционные тесты
Более высокий уровень абстракции, чем юнит-тесты.
Тестирует функциональность системы (в частности класса) в связке с окружением и зависимостями. К тому же, тестируется взаимодействие составных частей (к примеру, последовательность состояний класса).
Признаки:
- Тесты используют реальную инфрастуктуру: потоки, БД, файловую систему, зависимости системы
- Тесты проверяют взаимодействие компонентов
Приемочные/функциональные тесты
Еще более высокий уровень абстракции, чем интеграционные тесты.
Тестируются фичи и их согласованность со спецификацией. По большей части провеярется то, что система производит нужный ответ на заданный ввод. При этом нас не интересует внутреннее состояние компонентов системы. Можно сказать, что система в приемочных тестах — черный ящик.
Признаки:
- Тесты пишутся с точки зрения клиента системы
- Тесты ориентированы на проверку ключевых требований, предъявляемых к конкретной фиче
- Тесты проверяют соответствие ожиданий (спецификацию) и реальности
Итого: эти виды тестов не исключают друг друга. Они находятся на разных уровнях абстракции. Можно сказать, что юнит-тесты и интеграционные тесты делают проверки с точки зрения программиста, а функциональные тесты — с точки зрения клиента кода.
И да — бывают смешанные типы. К примеру, нам лень мокать зависимость от БД, но мы пишем «типа юнит-тест». В итоге получаем «интеграционный юнит-тест»(с минимальной зависимостью от БД) который в первую очередь проверяет поведение метода и в качестве стороннего эффекта — интеграцию этого поведения с БД.
Использование тестов это вопрос саморазвития программиста. Тест это формализованное описание задачи, которую ты собираешься решать. В некотором смысле — это проверка на то, что ты правильно понимаешь суть задачи.
Принципиальная вещь — тест должен быть простой на столько, чтобы можно было 15-20 сек. понять что он проверяет. Если тест превращается в кучу непонятного кода, то это верный признак, что вы что-то делаете неправильно.
Когда я начинаю тупить, я обычно задаю себе вопрос: Как я буду проверять работоспособность кода, который я собираюсь написать? Если проверка слишком сложная, то это верный признак, что задачу нужно дробить…
И да… Важный момент — инструментами тестирования надо владеть. Первое время нужно тупо тренироваться в написании тестов для своей предметной области… Можете вместе коллегами устроить соревнование на самый простой и красивый тест. Умение писать красивые тесты — это отдельный скилл…
Принципиальная вещь — тест должен быть простой на столько, чтобы можно было 15-20 сек. понять что он проверяет. Если тест превращается в кучу непонятного кода, то это верный признак, что вы что-то делаете неправильно.
Когда я начинаю тупить, я обычно задаю себе вопрос: Как я буду проверять работоспособность кода, который я собираюсь написать? Если проверка слишком сложная, то это верный признак, что задачу нужно дробить…
И да… Важный момент — инструментами тестирования надо владеть. Первое время нужно тупо тренироваться в написании тестов для своей предметной области… Можете вместе коллегами устроить соревнование на самый простой и красивый тест. Умение писать красивые тесты — это отдельный скилл…
Sign up to leave a comment.
Почему изучать TDD трудно и что с этим делать. Часть 2