Pull to refresh

Comments 10

Заглушки и фейковые сервисы — это хорошо и правильно.
Но еще, неплохо бы, таки делать тесты на реальных сервисах. Пусть не в рамках CI, но периодически. Чтобы, как минимум, узнать, работает ли сервис вообще и не тормозит ли он (согласитесь, озвученные вами временные интервалы до 2-х часов — это не есть гут). И вовремя предупредить своих клиентов о возможных проблемах.
Я это упомянул в статье. Это должен быть отдельный набор тестов, который дает исчерпывающую информацию о внешнем сервисе. Тогда и ваши тесты не тормозят и о возможных проблемах с внешними сервисами вы все знаете. А частота запуска может быть любая, в зависимости от ваших требований.
Сорри, точно. Недостаточно внимательно прочитал.
Mock и Spy, Stub и Dummy — синонимы.
Для тестирования внешних сервисов сохраняют ответы, тогда следующие прогоны можно делать без обращения к источнику. Возможность прогнать тесты по живым сервисам естественно остается. В руби-экосистеме для этих целей существует инструмент VCR (https://github.com/vcr/vcr).
Заводить два практически идентичных набора тестов не надо, это вредный совет.
Вы глубоко заблуждаетесь, считая Mock и Spy, Stub и Dummy синонимами. Они различны как по своей сути так и по области применения. Например, в качестве Dummy объекта часто может выступать NULL, а в качестве Stub не может. И благодаря этим отличиям, вы можете часто сэкономить много времени на их создание и понимание другими разработчиками. О тонкостях прочитайте по ссылке в статье. А вообще, настоятельно рекомендую книгу «xUnit Test Patterns: Refactoring Test Code».
Так и есть, вижу разницу. Mock устанавливает ожидания до выполнения, Spy — после. По сути они схожи. Stub ближе к этим двум, чем к Dummy, который стоит особнячком и по сути является значением, вроде NULL, «dummy value» и т.п.
В своей практике я использую Mock/Stub, никогда — Spy и часто Dummy, даже не зная что это так называется. За что и поплатился.
Приведу еще один пример, когда это очень важно. Вы берете mocking библиотеку, которая построена на самом деле на Spy. В итоге вы прописываете в тесте ожидания к вызовам методов, но в конце не проверяете, что они действительно были вызваны (так как не ожидаете поведение Spy). В итоге имеете кучу тестов, которые мало что тестируют.
Для предотвращения таких ошибок существует Mutation testing — изменение кода с последующей проверкой теста на провальность. Можно вручную, есть и инструменты.
еще как вариант можно использовать прокси

не знаю как в java, но в ruby есть vcr — в первый раз он записывает сетевые запросы и ответы на диск, все остальные берет данные с диска
Я про прокси писал в одном из пунктов. Это отличный способ.
Sign up to leave a comment.

Articles