Я бы сказал, что это на самом деле не модульный тест - вы пытаетесь загрузить что-то во внешнюю службу, которую вы не можете контролировать и не можете гарантировать, что результаты будут такими же, как у беги беги.
Вы написали интеграционный тест , который проверяет, как два или более программных компонента работают вместе. В этом случае два компонента
- Ваш код
- API загрузки в облако
В интеграционных тестах нет ничего плохого, но они, как правило, медленнее (в данном случае из-за загрузки файла в облако), и они, как правило, более хрупкие. Например, ваш интеграционный тест не будет работать, если облачный сервис недоступен. Ничего не изменилось в вашем коде, ничего не изменилось в вашем тесте, но результаты теста были другими.
Если вы хотите провести модульное тестирование своего метода UploadToCloud
, я бы рекомендовал вам начать с оборачивания вашей функциональности «облачной загрузки» в классе, который реализует интерфейс, например, ICloudUploader
. Затем вы можете смоделировать фрагменты, которые фактически связываются с вашим облачным сервисом, и убедиться, что функциональность вашего кода верна во всех ситуациях, которые вы хотите проверить (успешная загрузка, служба недоступна, загрузка не удалась) из-за слишком большого размера файла).
Для макетирования класса вы можете либо свернуть свой собственный (написать класс, который реализует ваш интерфейс, например, public class FakeCloudUploader : ICloudUploader
, либо заглянуть в фальшивую среду, например Moq или RhinoMocks .
Что касается предоставленного вами метода тестирования, то на самом деле он не проверяет вывод метода. Должно быть подтверждено, что строка, которую вы возвращаете из UploadToCloud
, является ожидаемым значением.