Как делают Вас модульный тест класс, который зависит от многих других классов?

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

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

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

В наших разработчиках проекта несут ответственность записи и поддержания тупиков с самого начала.

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

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

Поблочное тестирование увеличивает уверенность во мне как разработчик программного обеспечения.

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

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

Но мой вопрос находится в крупных проектах, где каждый класс зависит от многих других классов, как Вы идете о поблочном тестировании класс?

Во-первых, Вы понимаете, что "каждый класс зависит от многих других классов", плохая вещь, правильно? И это это не функция наличия крупного проекта, а скорее плохого дизайна? (Это - одно из преимуществ TDD, что он имеет тенденцию препятствовать такому очень двойному коду.)

Гашение любого класса не имеет большого смысла и из-за сложности и из-за время, требуемое записать тупики.

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

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

public int foo(A a, B b) {
  C c = a.getC();
  D d = b.getD();

  Bar bar = calculateBar(c, d);

  return calculateFoo(bar, this.baz);
}

Bar calculateBar(C c, D d) {
  ...
}

int calculateFoo(Bar bar, Baz baz) {
  ...
}

Теперь я могу записать тест для calculateBar и calculateBaz, но я не должен волноваться в установке внутренних состояний (this.baz), и я не должен волноваться о создании ложных версий A и B.

После создания тестов как это с существующими интерфейсами затем я ищу возможность выставить изменения в интерфейсе, как изменение метода Foo для взятия C и D, а не A и B.

Какое-либо из этого имеет смысл?

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

Если классы, используемые тем, который Вы тестируете, были уже протестированы, то хорошо иметь тестовый охват по нескольким классам.

Это иногда более простой дразнить объект: когда

• объект является или использует внешний ресурс, такой как соединение с базой данных или сетевое соединение, диск
• объектом является GUI
• объект еще не доступен
• поведение объекта не детерминировано
• объект является дорогим для установки