Зачем мне нужны рамки для моих юнит-тестов?

Question

В последнее время было довольно много шумихи вокруг разных фальшивых фреймворков в мире .NET. Я до сих пор не совсем понял, что в них такого хорошего. Кажется, не сложно написать объекты-насмешки, которые мне нужны сами. Особенно с помощью Visual Studio я быстро могу написать класс, который реализует интерфейс, который я хочу смоделировать (он автоматически генерирует почти все для меня), а затем написать реализацию для метода (ов), который мне нужен для моего теста. Готово! Зачем преодолевать трудности в понимании фреймворк-фреймворка с единственной целью сохранить несколько строк кода. Или насмешливая структура не только для сохранения строк кода?

Answer 1

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

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

Answer 2

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

Что вы делаете, если вы тестируете, например, ICustomerDAO, и вы хотите протестировать какой-то метод по 14 раз каждый с разными результатами? Реализовать 14 разных классов вручную? Я сомневаюсь, что кто-то захочет это сделать.

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

Это отличный инструмент для юнит-тестирования.

Answer 3

Предыдущие вопросы, которые могут помочь:
Что такое макет и когда его использовать?
Mockist против классического TDD

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

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

Answer 4

Рой Ошеров провел опрос о Mock Frameworks, и в разделе комментариев идет дискуссия (пусть и краткая) о том, нужен ли Mock Framework или нет.

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

Answer 5

Ну, я, конечно, не думаю, что вам НУЖНА насмешка. Это фреймворк, как и любой другой, и в конечном итоге он разработан, чтобы сэкономить ваше время и усилия. Вы также можете делать такие вещи, как свертывать свои собственные общие структуры данных, такие как стеки и очереди, но разве не проще просто использовать те, которые встроены в библиотеки классов, которые поставляются с компилятором / IDE на вашем языке?

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

Answer 6

Одна вещь, которая беспокоит меня о фальшивом фреймворке, это то, что «какая функция должна быть сделана через i / p» через

when (mock.someMethod («некоторый аргумент»)). ThenReturn («что-то»);

оператор распространяется на многие классы модульных тестов.

Позвольте мне привести пример. Допустим, была функция интерфейса DAO getEmp (int EmpID), которая возвращала объект Employee при передаче идентификатора сотрудника в качестве параметра. Предположим, что эта функция была смоделирована 10 различными классами модульных тестов. Теперь, если в будущем эта функция была изменена так, чтобы она возвращала более новую версию объекта Employee, нужно было бы перейти к каждому из 10 различных классов, чтобы обновить это изменение.

Недостатки заключаются в следующем ...

a) Я не знаю, как выяснить все классы, которые высмеивают эту функцию, чтобы я мог обновить это изменение.

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

Любые мысли о моих взглядах ..

Answer 7

По той же причине вы не пытались бы писать модульные тесты без NUnit. Фреймворк поможет вам проверить состояние и поведение на протяжении сотен модульных тестов. Чтобы набрать скорость, нужно потратить около двух недель, и это действительно поможет вам сосредоточиться на том, что нужно проверить.

Answer 8

Я использую насмешки носорога для насмешливой основы. Я и 5 других разработчиков использовали его в большом корпоративном приложении, которое было 8-месячным проектом. Мы использовали tdd в проекте. Стоило ли? Похоже. Была ли такая огромная точка продажи с использованием насмешек, что мне приходилось использовать это в каждом проекте? На мой взгляд, нет. Это не то, что необходимо, это просто инструмент, который вы можете использовать, если хотите попробовать. В некоторых проектах вы можете развернуть свои собственные ложные классы, как некоторые здесь говорят, что они предпочитают - это проще. Другие проекты больше и могут потребовать насмешливых рамок. Ключевое слово (на мой взгляд) МОЖЕТ требовать ... какой охват кода вам требуется? Для меня это еще одно соображение по поводу использования насмешек. В проекте, который я сделал с ментами tdd / rhino, мы должны были охватить 80% кода, поэтому моты помогли нам достичь этого. Если бы наши требования к покрытию кода были меньше, например, на 40%, мы, вероятно, не использовали бы фальшивый фреймворк и просто написали бы наши собственные фиктивные классы, как другие упоминают, что они делают.

Answer 9

Фреймворк изоляции или фреймворк позволяет вам тестировать необходимый код без его зависимостей. Это позволяет проводить короткие тесты, позволяет быстро отлаживать и легко создавать защитную сеть для тестов вокруг кода. Разные фреймворки имеют разные функции, и, как уже было сказано, это инструмент, и вы должны выбрать правильный инструмент для работы.

Answer 10

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