Как “mockist” практик TDD, я должен дразнить другие методы в том же классе как метод под тестом?
Вы можете создать следующую команду с помощью Visual Commander (язык: C #) и назначить ярлык для закрытия Solution Explorer:
public class C : VisualCommanderExt.ICommand
{
public void Run(EnvDTE80.DTE2 DTE, Microsoft.VisualStudio.Shell.Package package)
{
var serviceProvider = package as System.IServiceProvider;
var shell = (Microsoft.VisualStudio.Shell.Interop.IVsUIShell)serviceProvider.GetService(typeof(Microsoft.VisualStudio.Shell.Interop.SVsUIShell));
var SolutionExplorer = new System.Guid(Microsoft.VisualStudio.Shell.Interop.ToolWindowGuids80.SolutionExplorer);
Microsoft.VisualStudio.Shell.Interop.IVsWindowFrame frame;
shell.FindToolWindow(0, ref SolutionExplorer, out frame);
frame.Hide();
}
}
7 ответов
Техника неспроста называется «имитация объектов», а не «фиктивные методы». Он поощряет проекты, которые делят систему на легко составляемые, взаимодействующие объекты, не связанные с процедурным кодом. Цель состоит в том, чтобы поднять уровень абстракции, чтобы вы в основном программировали, составляя объекты, и редко пишите операторы потока управления низкого уровня.
отредактированный для нового примера
Мне похоже, что Вы блокируете confirm_or_create_connection, Вы только интересуетесь определением ответного визита, и Вы дразните синхронизацию, здесь Вы интересуетесь тестированием, если это действительно называют. (Я должен буду проверить, совпадает ли мое определение блокирования или насмешки с fowler статьей, Вы сослались. Прошло некоторое время, так как я считал его, и я использовал rhinomocks в c#, который мог бы иметь свое собственное определение этих условий :-))
Я думаю, на какой Вы тестируете насмешку и блокирование тех вызовов, правильный способ пойти. Вы не хотите тестировать, чтобы перестать работать, если одна из тех функций имеет ошибку, существуют другие тесты для этого. Вы просто хотите протестировать операцию sync_path.
Я соглашаюсь с Avdi, что это является довольно вонючим. Тесты в порядке, но Ваш класс мог бы делать слишком много.
Лично я думаю, что насмешка на сам является почти всегда запахом кода. Это тестирует реализацию, а не поведение.
Можно ли взять насмешку слишком далеко? Я не знаю о слишком далеком, но это может иметься проблемы таким образом, что Вы на самом деле тестируете насмешки вместо кода, или хуже так, чтобы у Вас были хрупкие тесты.
Но, пока Вы пишете хорошие тесты — тесты, которые подтверждают Ваше ожидаемое поведение, тесты, которые помогают, Вы написать код — затем дразните на!
Отредактировано для обновленного образца:
Теперь понятно. У вас есть проблемы с тестированием этого класса, потому что он имеет недостатки конструкции. Этот класс нарушает принцип единственной ответственности. Он делает две вещи. Во-первых, это управление подключением к базе данных. Это также синхронизация.
Вам нужен отдельный класс для управления подключением к базе данных. Этот класс будет зависимостью от тестируемого класса. Класс подключения к базе данных может быть подделан при модульном тестировании тестируемого класса.
Ранее:
Как другой тестировщик взаимодействия, подумайте о рефакторинге, если у вас есть нужно это сделать. Этот класс вероятно, делает слишком много.
Позвольте мне сказать вам это так: звоню частный метод не делает взаимодействие.
Это один из основных пунктов TDD. Когда тебе больно, твой дизайн может быть улучшено.
Как ни странно, похоже, что активность соединения может принадлежать другому объекту, которому следует делегировать полномочия, и в этом случае вы можете издеваться над над . Обычно я рекомендую не издеваться над одной частью объекта, чтобы протестировать другую. Это предполагает, что есть две концепции, связанные вместе.
Вот хорошее прочтение: «Принцип: не изменяйте SUT» на http://xunitpatterns.com/Principles%20of % 20Test% 20Automation.html # Don
Изменение класса, который вы тестируете, путем имитации или подстановки частей его реализации - это запах кода. Рефакторинг, чтобы избавиться от этого, - это переместить часть, которую вы высмеиваете / заглушаете, в другой класс. Тем не менее, это не всегда ужасно. Это запах кода, но он не всегда неуместен. Для таких языков, как C # или Java, где у вас есть хорошие инструменты рефакторинга, этот запах кода легко исправить, и я обычно это делал (в C #, при условии, что Java похожа). Однако я много занимаюсь разработкой на Lua и Javascript, где все немного по-другому. Создавать и управлять большим количеством классов на этих языках сложнее, поэтому я более терпимо отношусь к изменению SUT в тестах. Это всегда что-то, что я могу исправить позже, как только начнется первоначальное тестовое покрытие. Это требует особого ухода.