По определению, зависимости должны быть разбиты в производственном коде, чтобы сделать его более тестируемым, т.е. чтобы сделать производственный код более тестируемым, вам нужно изменить код, чтобы сделать его менее связанным с реальными реализациями. Это позволит вам заменить фиктивные объекты на реальные объекты в тестируемом классе в ваших тестах. Это устраняет зависимость от других производственных классов, от которых зависит тестируемый класс.
Если вы написали слабосвязанный производственный код - код, который опирается на интерфейсы, а не на реализации, который использует фабрики и внедрение зависимостей для создания объектов, а не для прямой реализации - тогда вам может потребоваться лишь внести небольшие изменения или ничего не делать вообще к вашему производственному коду. Если нет, то вам нужно будет внести эти типы изменений. Однако это не так уж плохо, так как улучшит ваш дизайн за счет уменьшения связи между классами. Стоимость этого будет составлять несколько дополнительных (небольших) классов и / или интерфейсов, которые делают возможной изоляцию.
Если вы используете TDD (Test Driven Development / Design), типы конструкций, которые вы используете в своем рабочем коде, изменятся, чтобы сделать его более естественным для тестирования. Это один из способов, с помощью которых TDD работает над улучшением дизайна и включением тестирования в ваш код.
Обратите внимание, что вам не нужно вводить связи или зависимости в вашем рабочем коде в ваш тестовый код. Ваш тестовый код, очевидно, будет зависеть от производства, и вам может потребоваться рефакторинг зависимостей в производстве, чтобы сделать его более тестируемым, но если ваш производственный код «знает» что-либо о том, как он тестируется, вы, вероятно, сделали что-то не так. Вы, вероятно, ввели искусственные интерфейсы, когда должны использовать внедрение зависимостей.