Необходимо ли только дразнить типы, которыми Вы владеете?
Я прочитал TDD: Только насмешка вводит Вас собственная запись Mark Needham и хотела бы знать, является ли это лучшей практикой или нет?
Обратите внимание на то, что он не против насмешки, а против насмешки непосредственно - он действительно говорит, что запись обертки и насмешка, который прекрасен.
5 ответов
Depends whether you mean mock or mock™…
Given you are just using a mock framework (as eg Mockito) to create stubs, then creating stubs of types you don't own is totally okay and reasonable.
If however, you are using a mock framework (as eg Mockito) to create mock™ objects, then you best literally follow the advice of the mock™ evangelists. Personally I lost touch to that movement, so I cannot tell you whether Mark Needham's advice is to be considered kosher or not.
Irony aside, what Mark writes about mocking of EntityManagers in Hibernate sounds reasonable by itself. But I doubt that we can generalize a rule like "never mock types you don't own" from that specific case. Sometime it might make sense, sometimes not.
Мой ответ - «нет». Вы должны высмеивать все, что имеет смысл в контексте данного модульного теста. Не имеет значения, «владеете» вы имитируемым типом или нет.
В наши дни в среде Java или .NET все (и я действительно имею в виду все) можно легко высмеять. Итак, нет никаких технических причин, чтобы утруждать себя первым делом написания дополнительного кода оболочки.
Некоторые дополнительные идеи, о которых я размышлял недавно (ноябрь 2010 г.), которые показывают, насколько нелогичным может быть «только имитировать типы, которыми вы владеете». :
- Предположим, вы создаете оболочку для стороннего API, а затем имитируете оболочку в модульных тестах. Однако позже вы поймете, что оболочку можно повторно использовать в другом приложении, поэтому переместите ее в отдельную библиотеку. Теперь обертка больше не принадлежит вами (поскольку он используется в нескольких приложениях, потенциально поддерживаемых разными командами). Следует ли разработчикам создавать новую оболочку для старой?!? И продолжать делать это рекурсивно, добавляя слой за слоем по существу бесполезного кода?
- Предположим, кто-то уже создал красивую оболочку для какого-то нетривиального API и сделал ее доступной как повторно используемую библиотеку. Если указанная оболочка - это именно то, что мне нужно для моего конкретного случая использования, следует ли мне сначала создать оболочку для оболочки с почти идентичным API, чтобы я "стал владельцем" ее?!?
Для конкретного и реалистичного примера рассмотрим API электронной почты Apache Commons, который является не чем иным, как оболочкой для стандартного API почты Java. Поскольку он мне не принадлежит, всегда ли я должен создавать оболочку для Commons Email API всякий раз, когда я пишу модульные тесты для класса, которому необходимо отправлять электронную почту?
I agree with Mark is saying. You can not unfortunately mock everything and there are somethings you don't want to mock, just because your normal use of it is a black box.
My rule of thumb is Mock things that will make the test fast but won't make the test flaky. Remember not all fakes are the same and Mocks are not Stubs.
I was going to say "no" but having had a quick look at the blog post I can see what he is on about.
He talks specifically about mocking EntityManagers in Hibernate. I am against this. EntityManagers should be hidden inside DAOs (or similar) and the DAOs are what should be mocked. Testing one line calls to EntityManager is a complete waste of your time and will break as soon as anything changes.
But if you do have third party code that you want to test how you interact with it, by all means.
Я, конечно, в меньшинстве, но я считаю мокинг запахом кода и использую инъекцию зависимостей вместо него, если это возможно. Причина в том, что мокинг - это, по сути, обходной путь для тестирования труднотестируемого кода. Мокинг ослабляет тесты, потому что они ведут себя (в лучшем случае) как определенная версия библиотеки. Если библиотека изменится, ваш тест потеряет всю свою проверочную ценность.
Вы можете видеть, читая вышеизложенное, что я использую аргументы Марка Нидхэма, но не для того, чтобы сказать, что вы не должны издеваться над объектами, которые вам не принадлежат, а что вы не должны издеваться вообще...
Хорошо, если внедрение зависимостей не является вариантом, тогда давайте подражать... но тогда вы должны понимать, что ваш тест - подделка и не будет вести себя как производственный код. Это не настоящий юнит-тест, а лишь частично подделанный. Если возможно, вы можете сделать его менее таким, добавив тесты, которые проверяют, что поведение подражаемых объектов соответствует ожидаемому.