Мог смоделировать модульные тесты быть действительно независимым и как [ASP.NET MVC]
Я плохо знаком с целым материалом поблочного тестирования, поэтому извините мое отсутствие опыта. Я считал много материалов, говоря, что никакой тест не должен зависеть от других, чтобы сделать, т.е. модульные тесты быть абсолютно независимыми формируют друг друга. Можно ли действительно сделать это в действительности? У меня есть следующий пример: у Меня есть несколько классов объекта друг в зависимости от друга, на основе определенной схемы базы данных (я использую Linq-для SQL для генерации их), Теперь, если я хочу протестировать каждый образцовый класс, я должен создать объект образцового класса, создать тестовый объект из каждой из его зависимостей, присвоить их свойствам объекта и затем сохранить объект прежде, чем проверить контекст и утверждать, что это на самом деле работает.
Это, очевидно, делает его намного тяжелее для создания тестов, которые не зависят друг от друга или не работают в определенной последовательности (я не делаю экземпляра Содержания типа, которое будет создано, прежде чем у меня будет по крайней мере один экземпляр типа ContentType), Зависимость, по крайней мере, на образцовом уровне присутствует и не может избежаться.
Подвергните критике меня много, если Вы думаете, что я неправ. Я хочу учиться.
P.S. Только, чтобы упомянуть, что я работаю над приложением MVC ASP.NET и тестирую с NUnit, если это имеет смысл
3 ответа
Да, модульное тестирование должно (и может) быть независимым. Проблема, которую вы описываете, касается зависимости. Зависимость должна быть разрешена с использованием фреймворков Dependency Injection (см. AutoFac, проекты Ninject).
Другое дело, что ваша база данных должна быть смоделирована с использованием фиктивных объектов (см. Проекты Moq, Rhino Mocks). Вам необходимо протестировать весь свой код, даже если ваша база данных отключена.
Другое дело, что модульный тест должен тестировать только одну функциональность, а не весь ваш процесс.
Да , вы действительно можете это сделать в реальности.
Ключ, позволяющий изолировать каждое устройство, заключается в написании слабосвязанного кода. Зависимость от классов LINQ to SQL (L2S) не является слабосвязанной, что объясняет ваши проблемы.
Вам было бы лучше определить набор интерфейсов, за которыми вы можете скрыть свой код L2S. Затем модель предметной области работает с этими интерфейсами, а не непосредственно с классами L2S.
Здесь вы описываете не модульные тесты, а интеграционный тест. Поскольку модель данных вашего приложения тесно связана с базой данных, ваши тесты, вероятно, проверяют функциональность базы данных, а не «модель данных».
Это прекрасно - просто имейте в виду, что интеграционные тесты нуждаются в настройке (в вашей базе данных) и требуют больше времени для выполнения.
У вас также, вероятно, есть модульные тесты для ваших контроллеров, которые могут быть полностью изолированы от других компонентов и не нуждаются в базе данных для запуска, это те модульные тесты, о которых вы говорите.
Если вы не тестируете фактическую функциональность базы данных, вы можете использовать фальшивый / фиктивный объект для замены внешних классов - на самом деле тесты, созданные с помощью исходного проекта MVC, содержат фальшивые объекты, скрученные вручную, которые делают именно это.
Другой способ «изолировать» ваши внешние зависимости - это деформировать код Linq2Sql вашим собственным классом и подделать эти вызовы классов с помощью фреймворка Mocking.