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

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

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

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

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

Ответ 1

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

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

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

Ответ 2

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

Плюсы:

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

Минусы:

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

Ответ 3

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

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

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

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

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

Ответ 4

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

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

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