Прямой, честный ответ заключается в том, что это будет крайне сложно правильно учесть для модульного тестирования сегодня без больших инвестиций в обход ограничений сегодняшних API.
Как вы указали в этом конкретном случаеcase OAuthPrompt
имеет strong , связанное со свойством ITurnContext::Adapter
, являющимся, в частности, экземпляром BotFrameworkAdapter
.Одно это «нехорошо», но в сочетании с тем фактом, что вы не можете переопределить API-интерфейсы на BotFrameworkAdapter
, которые OAuthPrompt
на самом деле должен вызывать, означает, что вы полностью застряли, если не используете продвинутую фальшивую среду, которая позволяетза замену не виртуальных участников.
Честно говоря, немного взглянув на это, я не думаю, что вы можете обойти это прямо сейчас.Я бы умолял вас поднять эту проблему в репозитории botbuilder-dotnet
на GitHub, и я с радостью перезвоню там с рекомендацией команде о том, как они могли бы исправить это.
ОБНОВЛЕНИЕ 8/ 15/2019
Начиная с первоначального ответа, он был реорганизован для введения интерфейса IUserTokenProvider
, который теперь OAuthPrompt
проверяет, поддерживает ли текущий ITurnContext::Adapter
, и, если это так, вызываетдо его реализации.Это означает, что теперь вы можете смоделировать этот интерфейс и реализовать подходящие сценарии для тестов.