Как Вы Устанавливаете свой Проект (проекты) Модульного теста в .NET?
- Никогда не хранят уязвимую информацию как пароли в cookie.
- не Делают сообщений об ошибках системы отображения, отслеживания стека и т.д. в случае исключения.
5 ответов
ИМО, если вы хотите упростить выполнение ваших тестов, тестовые проекты обязательно должны быть в том же решении, что и производственный код. Хотя включение тестов в другое решение может сработать, если все разработчики будут чрезвычайно старательными, это добавляет дополнительный барьер между изменением производственного кода и запуском тестов. Я предпочитаю убрать как можно больше препятствий.
Есть несколько способов сделать это.
- Один тестовый проект для одного решения (Product.UnitTests.csproj)
- Один тестовый проект для каждой системы (Product.SystemName.UnitTests.csproj)
- Один к одному сопоставление производственных проектов и тестовых проектов ( Product.ProjectName.csproj и Product.ProjectName.Tests.csproj)
У каждого из них есть свои компромиссы, которые вы должны взвесить.
Один тестовый проект для одного решения
Имеет смысл, если все решение содержит связанные проекты. Если вы всегда собираетесь разрабатывать одно и то же решение, хорошо иметь централизованный тестовый проект.
Это означает снижение накладных расходов на процесс сборки (когда у вас есть решения с большим количеством проектов, уменьшение количества сборок также сокращает время сборки) и отсутствуют накладные расходы на поддержку файлов .nunit и т.п.
Кроме того, все знают, куда идут тесты. Обратной стороной является то, что вам нужно разделить разные производственные проекты с помощью пространств имен, а тесты для одного проекта теперь связаны с другими. Т.е. это «самый простой» вариант для получения бай-ина, так как отслеживать меньше и разработчики могут легко запускать тесты. Обратной стороной является то, что в некоторых случаях это не подходит для того, что вы разрабатываете.
Один тестовый проект для каждой системы
В основном то же, что и выше, за исключением того, что он более детализирован. Вы группируете связанные проекты в области / системы и используете одну тестовую сборку для каждой. Это немного увеличивает сложность, но также означает, что системы легче извлекать / повторно использовать в других решениях.
Сопоставление производственных и тестовых проектов один-к-одному.
Имеет наибольшие накладные расходы с точки зрения создания новых сборок, немного увеличивает время сборки при большом количестве проектов и, как правило, увеличивает размер файла решения. Требует осмотрительности с точки зрения постоянного обновления файлов проекта .nunit и не очень хорошо работает с модульным тестированием в IDE.
Положительным моментом является то, что поддержка тестового проекта для каждого производственного проекта означает, что тесты зависят только от тестируемой функциональности (так что проще повторно использовать проекты), и вы можете легче проверить покрытие кода, запускать один проект за раз (тогда как если вы запустите все свои тесты, вы получите более высокий охват из-за несвязанных тестов, иногда затрагивающих код, который им не интересен). Кроме того, это простой шаблон, которому нужно следовать, чтобы люди без проблем поймут, где должны проходить тесты.
В итоге: я думаю, что любой из вышеперечисленных может хорошо работать в зависимости от того, что вы разрабатываете, но если вы Если нужно решение, которое «просто работает», тогда я бы предпочел сопоставление один-к-одному.
повторное тестирование (чтобы было легче повторно использовать проекты), и вам будет проще проверять покрытие кода, выполняя один проект за раз (тогда как если вы запустите все свои тесты, вы получите более высокий охват из-за несвязанных тестов, иногда затрагивающих код, который они не интересует). Кроме того, это простой шаблон, которому нужно следовать, чтобы люди без проблем поймут, где должны проходить тесты.В итоге: я думаю, что любой из вышеперечисленных может хорошо работать в зависимости от того, что вы разрабатываете, но если вы Если нужно решение, которое «просто работает», я бы предпочел сопоставление «один к одному».
повторное тестирование (чтобы было легче повторно использовать проекты), и вам будет проще проверять покрытие кода, выполняя один проект за раз (тогда как если вы запустите все свои тесты, вы получите более высокий охват из-за несвязанных тестов, иногда затрагивающих код, который они не интересует). Кроме того, это простой шаблон, которому нужно следовать, чтобы люди без проблем поймут, где должны проходить тесты.В итоге: я думаю, что любой из вышеперечисленных может хорошо работать в зависимости от того, что вы разрабатываете, но если вы Если нужно решение, которое «просто работает», я бы предпочел сопоставление «один к одному».
вы получите более высокий охват из-за несвязанных тестов, иногда затрагивающих код, который им неинтересен). Кроме того, это простой шаблон, которому нужно следовать, чтобы люди без проблем поймут, где должны проходить тесты.В итоге: я думаю, что любой из вышеперечисленных может хорошо работать в зависимости от того, что вы разрабатываете, но если вы Если нужно решение, которое «просто работает», тогда я бы предпочел сопоставление один-к-одному.
вы получите более высокий охват из-за несвязанных тестов, иногда затрагивающих код, который им неинтересен). Кроме того, это простой шаблон, которому нужно следовать, чтобы люди без проблем поймут, где должны проходить тесты.В итоге: я думаю, что любой из вышеперечисленных может хорошо работать в зависимости от того, что вы разрабатываете, но если вы Если нужно решение, которое «просто работает», я бы предпочел сопоставление «один к одному».
Я предпочитаю иметь тестовый проект в том же решении, что и мой исходный код, и группирую тесты, добавляя папки
Определенно единое решение, но отдельные проекты:
- Вы не t хотите, чтобы ваши тесты были частью вашей производственной сборки (зачем добавлять раздувание?)
- Вы не хотите переключаться между различными решениями, чтобы переключаться между тестовым кодом и производственным кодом; по моему опыту, это может серьезно нарушить ритм. (Однажды меня заставили использовать этот шаблон, и это было ужасно.) Это также нарушает рефакторинг - если вы измените метод в своем производственном коде, вы хотите, чтобы тесты автоматически использовали новое имя метода. (По общему признанию, названия некоторых тестов, возможно, придется изменить вручную.)
Один тестовый проект на рабочий проект мне подходит. Я стараюсь сделать пространство имен одинаковым как для тестов, так и для производственного кода,
У меня хорошо сработала следующая структура. Он также разделяет производственный и тестовый код.
\source
\source\code\MainSolution.sln
\source\code\Project1
\source\code\...
\source\test\TestSolution.sln
\source\test\TestProject1
\source\test\...
Имею одно и то же решение для обоих, но 2 проекта, проект .NET и проект NUnit (один к одному), теперь, если у меня есть решение, которое состоит из нескольких проектов, то у меня есть только 1 проект NUnit для решения в отдельности и по 1 для каждого проекта .. Я думаю, что это хороший способ, потому что он помогает мне организовывать мои проекты.
Кроме того, вы можете взглянуть на эту книгу: http: //www.artofunittesting.com/ очень хорошо.