Насмешки или реальные классы? [дубликат]

Хорошо использовать "реальную вещь", пока Вы имеете неограниченный контроль над объектом. Например, если у Вас есть объект, который просто имеет свойства и средства доступа, Вы, вероятно, в порядке. Если существует логика в объекте, Вы хотите использовать, Вы могли бы столкнуться с проблемами.

Если модульный тест на класс использование, экземпляр класса b и изменения, представленного b, повреждает b, то тесты для класса a также повреждаются. Это - то, где можно столкнуться с проблемами, где как с фиктивным объектом Вы могли всегда возвращать правильное значение. Используя "реальную вещь" Может вид свернутых тестов и скрывать настоящую проблему.

Насмешки могут иметь оборотные стороны также, я думаю, что существует баланс с некоторыми насмешками и некоторыми реальными объектами, которые необходимо будет найти для себя.

Существует одно действительно серьезное основание, почему Вы хотите использовать тупики/насмешки вместо реальных классов. Т.е. сделать Ваш модульный тест (чистый модульный тест) классом под тестом изолированный от всего остального. Это свойство чрезвычайно полезно, и преимущества для хранения изолированных тестов многочисленны:

• Тестовый прогон быстрее, потому что они не должны называть реальную реализацию класса. Если реализация должна работать против файловой системы или реляционной базы данных затем, тесты станут вялыми. Медленные тесты делают разработчиков не выполненными модульными тестами как часто. При выполнении Разработки через тестирование затем, время hogging тесты является вместе разрушительной пустой тратой времени разработчиков.
• Будет легче разыскать проблемы, если тест будет изолирован к классу под тестом. В отличие от тестирования системы будет намного более трудно разыскать противные ошибки, которые не по-видимому видимы в отслеживаниях стека или что нет.
• Тесты менее хрупки на изменениях, сделанных на внешних классах/интерфейсах, потому что Вы просто тестируете класс, который находится под тестом. Низкая хрупкость является также признаком слабой связи, которая является хорошей разработкой программного обеспечения.
• Вы тестируете против внешнего поведения класса, а не внутренней реализации, которая более полезна при решении дизайна кода.

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

Единственная вещь, которую необходимо иметь в виду, следующая:

• Насмешки и тупики для модульных тестов.

• Реальные классы для интеграции/тестирования системы.

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

Если это не так затем это зависит от сложности двух объектов. Тестирование объекта под тестом с реальной зависимостью по существу умножает два набора сложностей. Насмешка зависимости позволяет мне изолировать объект под тестом. Если любой объект довольно прост, то объединенная сложность все еще осуществима, и мне не нужна ложная версия.

Как другие сказали, определение интерфейса на зависимости и введение ее в объект под тестом делают намного легче дразнить.

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

Можно также найти эти связанные вопросы полезными:

• Что дразнит объект и когда мне нужен он?
• Когда я должен дразнить?
• Как насмешки предназначены, чтобы использоваться?
• И возможно даже, это - просто я, или интерфейсы злоупотребляются?

Используйте реальную вещь, только если это была единица, протестировал себя сначала. Если это представляет зависимости, которые предотвращают это (круговые зависимости или если это требует, чтобы определенные другие меры существовали сначала), затем используют 'ложный' класс (обычно называемый "тупиковым" объектом).

Я был очень подозрительными дразнившими объектами, так как я был укушен ими неоднократно. Они являются великими, когда Вы хотите изолированные модульные тесты, но у них есть несколько проблем. Главная проблема - то, что, если классу Порядка нужен набор объектов OrderItem и Вы дразните их, почти невозможно проверить, что поведение дразнивших соответствий класса OrderItem реальный пример (копирующий методы с соответствующими подписями обычно недостаточно). Несколько раз я видел системный сбой, потому что дразнившие классы не соответствуют реальным и там существовали не достаточно интеграционных тестов для ловли пограничных случаев.

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

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

То, что тест затем покрывает больше Вашей кодовой базы, является премией.

Я обычно нахожу, что легко сказать, когда я должен использовать ThingMock вместо RealThing:

• Когда я хочу проверить ожидания во взаимодействии с Вещью.
• Когда использование RealThing принесло бы нежелательные побочные эффекты.
• Или когда RealThing просто слишком тверд/неприятен для использования в тестовой установке.

Извлеченный и расширенный из моего ответа, Как делают меня объекты наследования модульного теста?"> здесь:

Необходимо всегда использовать реальные объекты, если это возможно.

Необходимо только использовать фиктивные объекты, если реальные объекты делают что-то, что Вы не хотите настраивать (как сокеты использования, последовательные порты, получать ввод данных пользователем, получать большие данные и т.д.). По существу фиктивные объекты для того, когда предполагаемое усилие реализовать и поддержать тест с помощью реального объекта больше, чем это реализовать и поддержать тест с помощью фиктивного объекта.

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

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

Если Вашими 'реальными вещами' являются просто объекты значения как JavaBeans затем, это прекрасно.

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

Это зависит от Вашего стиля кодирования, что Вы делаете, Ваш опыт и другие вещи.

Учитывая все это, нет ничего мешающего Вам использовать обоих.

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

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

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

Другими словами: Никакой ответ всегда не работает. Сохраните свое остроумие о Вас, наблюдайте то, что работает, что не делает и почему.

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

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