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

Как уже упоминалось, InternalsVisibleTo("AssemblyName") - хорошее место для начала тестирования унаследованного кода.

Внутренние методы все еще являются закрытыми в том смысле, что сборки вне текущей сборки не видят методов. Проверьте MSDN на большую информативность.

Другое дело рефакторизовать большой метод на более мелкие, более определённые классы. Проверьте этот вопрос о похожей проблеме, тестирование больших методов.

Лично я бы сделал составляющие методы внутренними, применил InternalsVisibleTo и проверил бы разные биты.

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

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

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

Получите книгу , эффективно работающую с Кодексом наследия Майкла Фитерса. Я прохожу через нее около трети пути, и в ней есть несколько методик для решения такого рода проблем.

Ваш вопрос подразумевает, что во всей подсистеме существует множество путей выполнения. Первая идея, которая приходит в голову, это "рефактор". Даже если ваше API останется однометодным интерфейсом, тестирование не должно быть "невозможным".

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

Честно говоря, я бы посмотрел, нет ли какого-нибудь способа разбить этот код на более управляемый раздел.

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

Тем не менее, если бы вы использовали разработку через тестирование (TDD), вы бы никогда не оказались в такой ситуации, поскольку было бы практически невозможно написать модульные тесты, управляющие этим типом API.

Похоже, что метод, подобный тому, который вы описываете, пытается делать слишком много вещей одновременно. Одним из ключевых преимуществ TDD является то, что он побуждает вас реализовывать свой код из небольших составных объектов вместо больших классов с негибкими интерфейсами.

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

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

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