В двух словах, что можно сказать о процессе Mocking в TDD?

Question

Я бы хотел почистить свой мозг, чтобы избежать путаницы. В двух словах, что можно сказать о процессе Mocking в TDD

1. Что за идея GREAT стоит за MOCKING ?
2. Среды Mocking предназначены только для того, чтобы избежать доступа к БД во время тестов, или они могут использоваться для чего-то другого?
3. Для новичков (таких как я) все ли рамки одинаковы или мне нужно выбрать одну по той или иной причине?

Answer 1

Я предлагаю вам начать здесь:

издевательства не окурки

Вероятно, именно эта статья заставила меня задуматься о Моксе. Конечно, имитируемый объект, как правило, тяжелый (иначе он может не стоить издеваться), но он не должен быть тяжелым в том смысле, что он сильно зависит от внешней системы, такой как база данных. Это может быть просто сложная часть, которую вам нужно выделить, чтобы эффективно тестировать только ваш класс, а не зависимость.

Answer 2

Помимо устранения баз данных и других медленных или вспомогательных проблем из тестируемого модуля, имитация позволяет вам начинать писать тесты для класса без необходимости реализации каких-либо сотрудничающих классов.

Когда вы разрабатываете какую-то часть функциональности, вы понимаете, что вам нужен какой-то другой класс или сервис, чтобы придерживаться принципа единой ответственности, но затем вам придется реализовать их, чтобы заставить работать первый, что, в свою очередь, продемонстрирует необходимость еще большего количества классов.

Если вы можете смоделировать или заглушить эти зависимости, то вы можете создать интерфейсы, на которые будет опираться этот первый класс, без необходимости реализовывать что-либо за пределами этого класса - просто вернуть готовые результаты из заглушек интерфейсов.

Это важный компонент подхода, основанного на тестировании.

Answer 3

1. Идея БОЛЬШОЙ : ОГРАНИЧИТЕ СФЕРУ ВАШИХ ИСПЫТАНИЙ Удаляя зависимости, вы устраняете риск неудачных тестов из-за зависимостей. Таким образом, вы можете сосредоточиться на правильности кода, который использует эти зависимости.
2. Mocking DB очень распространен, но вы можете смоделировать любую зависимость с помощью интерфейса. Например, в недавнем проекте мы издевались над веб-сервисом. Возможно, вы даже захотите высмеять другой бизнес-объект, просто чтобы убедиться, что вы не полагаетесь на правильность логики этого объекта.
3. Я бы выбрал тот, который кажется наиболее простым в использовании. Мок действительно хороший.