Код модульного тестирования, который вызывает статические методы

Я читал большинство вопросов, связанных с SO ( здесь , здесь и там ). {{1 }} Последний вопрос предлагает четыре альтернативы для создания кода, вызывающего статические методы, для модульного тестирования. Я хочу спросить о моем конкретном случае: у нас есть "уровень бизнес-логики" или проект "правил", который содержит 45 статических классов (без состояния, только статические методы). Более того, их нелегко проверить сами по себе: большинство из них обращаются к базе данных и файловой системе. В любом случае, это не так уж и плохо: для доступа к базе данных они используют уникальный экземпляр некоторого класса Mapper (все Mapper - Singletons). Каждый раз, когда я пытаюсь выполнить что-то модульное тестирование, я натыкаюсь на эту стену. Самая большая проблема в том, что это очень, очень важный код, и изменения в нем следует планировать очень тщательно. Мой вопрос: как мне сделать этот код более удобным для модульного тестирования? Должен ли я написать 45 интерфейсов и использовать инъекцию зависимостей? Даже в этом случае, как мне заглушить / имитировать картографов?

PS: Я читал «Работа с устаревшим кодом» Майкла Фезерса, поэтому прямые ссылки приветствуются (другие книги тоже :)

Edit : Поскольку некоторые люди говорят, что решения могут зависеть от платформы, я работаю над .NET (C # и немного VB.NET)