Поскольку модульное тестирование - это (почти всегда) тестирование белого ящика, вы можете просто посмотреть на исходный код тестируемого класса, чтобы увидеть его зависимости.
Список зависимостей, созданный каким-то автоматическим инструментом может звучать хорошо в теории, но по моему опыту это не очень поможет в любом случае - вам нужно пройти через зависимости один за другим , определить, какие из них являются реальными, важными с точки зрениятекущего теста, затем установите их / смоделируйте их правильно для вашего модульного теста.Эта часть не может быть автоматизирована (и я сомневаюсь, что она когда-либо будет).
Самый простой и лучший способ (для меня) добиться этого - начать выполнение теста с самого простого очевидного тестового приспособления, то есть обычноToBeTested tested = new ToBeTested().Если это удается, я добавляю вызов (ы) к желаемому методу (методам) объекта.Если это также удастся (т.е. не генерируются исключения во время выполнения), я добавляю утверждения.Если (когда) какой-либо из этих шагов потерпит неудачу, я изучаю / отлаживаю код, чтобы увидеть, что пошло не так, и расширяю тестовое приспособление, чтобы покрыть это.
В лучшем случае (TDD в вашем собственном коде, будучиразработано заново) этот процесс, конечно, намного проще, так как класс с самого начала разработан для тестирования, поэтому он имеет минимальное количество зависимостей, и вы уже знаете их.В худшем случае (написание модульных тестов для унаследованного кода) это может быть болезненным, но полезным процессом исследования и, возможно, рефакторинга, для создания первого рабочего теста может потребоваться несколько часов.Но следующий будет намного проще, и после 3-го я почти всегда начинаю производить больше тестов, как конвейерная лента.