Какова практика добавления тестов Nunit в существующее решение?

Question

Я унаследовал решение ASP.net разумного размера, в котором нет автоматических тестов. Кажется, что решение включает в себя все исходные тексты / страницы в одном решении без различий в именах и разделения уровней, поэтому существуют прямые вызовы SQL внутри кода за файлами и т. Д.

Прежде чем вносить изменения в этот сайт, я хотел бы добавить несколько модульных тестов, желательно с использованием nunit, поскольку я знаком с моделью Xunit, чтобы придать мне уверенность в том, что я ничего не сломал. У меня нет большого опыта работы с .net, и, в частности, я не уверен в том, когда использовать проекты против решений и т. Д., Хотя я доволен базовым синтаксисом и т. Д. C #.

Каков рекомендуемый метод добавления юнит-тестов в решение? Должен ли я создать отдельное Решение / Проект для тестов, а затем добавить ссылки на соответствующие элементы существующего решения или создать отдельный проект в существующем решении для размещения набора тестов.

Я действительно ищу плюсы и минусы обоих подходов или вообще другого метода. Каковы опыты людей о наилучшем способе достижения этой цели?

Answer 1

Я не уверен, что вы можете начать с юнит-тестов. Помня, что первое правило - «Не ломай то, что работает», я бы предложил начать с некоторых интеграционных или регрессионных тестов, используя что-то вроде WatiN или Selenium. Обе из этих платформ могут запускать интеграционные тесты из платформ модульных тестов, таких как NUnit. Telerik тоже делает один, но он не бесплатный, и я им не пользовался.

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

Это я бы сделал, имея один проект, содержащий все модульные тесты, со ссылками на проекты, содержащие классы, которые вы тестируете. Я считаю, что это хорошая практика - разделять ваши уровни на проекты.

Answer 2

Я предпочитаю новый проект в том же решении.

Плюсы:

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

Минусы:

1. Вы создаете параллельную иерархию пространства имен, которую следует поддерживать, если перемещаете тестируемый код. Инструменты вроде resharper делают это проще.
2. Visual Studio немного медленнее, когда есть много проектов. Не проблема для меньшего количества проектов.

Answer 3

Я бы поместил тесты в другой проект в то же решение, чтобы они не распространялись вместе с рабочими версиями.

Посмотрите на Эффективно работая с устаревшим кодом Майкла Фезерса, у него есть масса советов по внедрению модульных тестов в непроверенный код.

Существуют рефакторинги, упрощающие модульные тесты и не изменяющие логику программы (например, встроенные в Visual Studio), их можно использовать на начальных этапах для улучшения структуры программы.

Не бойтесь сделать ваш код «хуже» на начальных этапах, чтобы включить модульное тестирование (например, сделать методы или поля общедоступными, которые должны быть приватными, или сделать все виртуальным), если вы делаете код лучше, когда испытания на месте.

Это включает временное добавление тестов в сам рабочий код: первое дело - тестирование кода, позже вы можете перенести тесты.

Answer 4

Я бы также порекомендовал прочитать статью «Эффективная работа с устаревшим кодом» Майкла Фезерса.

Что касается структуры решения при работе с устаревшим кодом, я обычно делаю копию существующего файла решения, называемого его <> Test.Sln, и добавляю новый проект UnitTests во вновь созданный файл решения.

Я добавляю еще один тестовый проект для интеграционных тестов, поскольку мне нравится отделять модульные тесты от интеграционных тестов.