Ви ставите тестові одиниці в тому ж проекті чи іншому проекті?

Ви ставите тестові одиниці в одному проекті для зручності чи ви ставите їх в окрему збірку?

Якщо ви помістите їх в окрему збірку, як і ми, ми закінчимось рядом додаткових проектів у рішенні. Він відмінно підходить для тестування одиниць під час кодування, але як ви можете випустити додаток без усіх цих додаткових збірок?

На мою думку, одиничні випробування повинні бути розміщені в окремій збірці від виробничого коду. Ось лише кілька мінусів розміщення одиничних тестів у тій же збірці або збірках, що і виробничий код:

1. Одиничні випробування постачаються з виробничим кодом. Єдине, що постачається з кодом товару - це виробничий код.
2. Збори будуть непотрібно роздуті одиничними тестами.
3. Експериментальні випробування можуть впливати на процеси нарощування, такі як автоматичне або безперервне збирання.

Я не знаю жодних плюсів. Наявність додаткового проекту (або 10) - це не підступ.

Редагувати: Детальніше про збірку та доставку

Я б далі рекомендував, щоб будь-яке автоматизоване процес збирання розміщувало виробничі та одиничні тести в різних місцях. В ідеалі процес збірки тестових одиниць запускається лише в тому випадку, якщо виробничий код будується та копіює файли продукту в каталог тестів одиниць. Це робиться таким чином, що фактичні біти відокремлюються для доставки тощо. Крім того, досить тривіально запустити автоматичне тестування одиниць у цей момент на всіх тестах у певному каталозі.

Підводячи підсумок, ось загальна ідея щоденного складання та тестування та доставки бітів та інших файлів:

1. Виконання збірки виробництва, розміщення виробничих файлів у конкретному "виробничому" каталозі.
   1. Створюйте лише виробничі проекти.
   2. Скопіюйте складені біти та інші файли у каталог "виробництво".
   3. Скопіюйте біти та інші файли в каталог кандидатів до випуску, він також буде "Release20081225".
2. Якщо нарощування виробництва успішно, працює тестова збірка одиниць.
   1. Скопіюйте виробничий код у каталог "тести".
   2. Побудуйте одиничні тести до каталогу "тести".
   3. Виконати одиничні тести.
3. Надсилайте розробникам сповіщення про складання та результати тестів на одиниці.
4. Коли кандидат у випуск (наприклад, Release20081225) приймається, надсилайте ці біти.

Окремий проект, але з тим же рішенням. (Я працював над продуктами з окремими рішеннями для тестового та виробничого коду - це жахливо. Ви завжди перемикаєтесь між цими двома.)

Причини окремих проектів вказані іншими. Зауважте, що якщо ви використовуєте тести, керовані даними, у вас може виникнути досить значна кількість, якщо ви включите тести у виробничу збірку.

Якщо вам потрібен доступ до внутрішніх членів виробничого коду, використовуйте InternalsVisibleTo .

Я не розумію частого заперечення проти розгортання тестів з виробничим кодом. Я очолив команду на невеликій мікрокапці (виріс з 14 до 130 осіб). У нас було півдесятка або близько додатків Java, і ми виявили, що НАЙКРАЙНО цінно для розгортання тестів у полі для їх виконання на певномумашина, яка проявляла незвичну поведінку. Випадкові проблеми трапляються на місцях, і можливість викинути кілька тисяч одиниць тестів при загадці з нульовою вартістю було неоціненним і часто діагностували проблеми за лічені хвилини ..., включаючи проблеми з установкою, невмілі проблеми з ОЗУ, специфічні для машини проблеми, несправні проблеми з мережею, і т. д. і т. д. Я вважаю, що надзвичайно цінним є тести на місцях. Крім того, випадкові проблеми спливають у випадкові часи, і приємно, щоб одиничні тести сиділи там, вже чекаючи їх виконання на мить. Місце на жорсткому диску дешево. Подібно до того, як ми намагаємось зберігати дані та функції разом (OO design), я думаю, що у зберіганні коду та тестів є щось принципово цінне (функція + тести, які підтверджують функції).

Я хотів би поставити свої тести в той же проект у C # /. NET / Visual Studio 2008, але я все ще не досліджував цього, щоб досягти цього.

Одним з головних переваг збереження Foo.cs у тому ж проекті, що і FooTest.cs, є те, що розробникам постійно нагадують, коли в класі відсутній тест для рідних братів! Це заохочує кращі практики тестування на основі тестування ... отвори більш очевидні.

Для кращої інкапсуляції поставте тестові модулі в той же проект, що і код.

Ви можете легко протестувати внутрішні методи, а це означає, що ви не будете оприлюднювати методи, які повинні бути внутрішніми.

Також дуже приємно, щоб одиничні тести були близькими до коду, який ви пишете. Коли ви пишете метод, ви можете легко знайти відповідні тестові одиниці, оскільки це в одному проекті. Коли ви будуєте збірку, що включає unitTests, будь-які помилки в unitTest дадуть вам помилку компілятора, тому ви повинні постійно оновлювати свій тест, просто для створення. Маючи тест на одиничні проекти в окремому проекті, це може змусити деяких розробників забути побудувати проект unittest і пропустити пробиті тести на деякий час.

А ви можете вилучити одиничні тести з виробничого коду, використовуючи компіляційні теги (ЯКЩО #Debug).

Тести автоматичної інтеграції (зроблені в NUnit) повинні бути окремим проектом, оскільки вони не належать ні до одного проекту.

Провівши деякий час у проектах TypeScript, де тести часто розміщуються у файлі поряд із кодом, який вони тестують, я вирішив віддавати перевагу такому підходу, ніж зберігати їх окремо:

• Швидше перейти до тестового файлу.
• Легше запам'ятати перейменування тестів, коли ви перейменовуєте тестований клас.
• Легше запам'ятати переміщення тестів, коли ви переміщуєте клас, який тестується.
• Це відразу очевидно, якщо в класі відсутні тести.
• Вам не потрібно керувати двома дублікатними файловими структурами, одну для тестів та одну для коду.

Тож коли я нещодавно розпочав новий проект .NET Core, я хотів побачити, чи можна імітувати цю структуру в проекті C # без доставки тестів чи тестових збірок з остаточним випуском.

Подання наступних рядків у файл проекту, здається, працює добре зараз:

  <ItemGroup Condition="'$(Configuration)' == 'Release'">
    <Compile Remove="**\*.Tests.cs" />
  </ItemGroup>
  <ItemGroup Condition="'$(Configuration)' != 'Release'">
    <PackageReference Include="nunit" Version="3.11.0" />
    <PackageReference Include="NUnit3TestAdapter" Version="3.12.0" />
    <PackageReference Include="Microsoft.NET.Test.Sdk" Version="15.9.0" />
  </ItemGroup>

Вищезазначене гарантує, що в Releaseконфігурації всі названі файли *.Tests.csвиключаються з компіляції, а також видаляються необхідні посилання пакета тестування одиниць.

Якщо ви все ще хочете мати можливість тестувати класи в конфігурації їх випуску, ви можете просто створити нову конфігурацію, похідну від Releaseчогось подібного ReleaseContainingTests.

Оновлення: Після деякого використання цієї техніки я також виявив, що корисно налаштувати ваші іконки у коді VS, щоб тести (та інші речі) виділялися трохи більше на панелі провідника:

Для цього скористайтеся розширенням Тема Значка Матеріал та додайте щось подібне до Ваших налаштувань коду VS JSON:

"material-icon-theme.files.associations": {
  "*.Tests.cs": "test-jsx",
  "*.Mocks.cs": "merlin",
  "*.Interface.cs": "yaml",
}

Мої одиничні тести завжди проходять в окремому проекті. Насправді для кожного проекту, який я маю в своєму рішенні, є окремий тестовий проект, який йде разом з ним. Код тестування не є кодом програми, і його не слід змішувати. Однією з переваг збереження їх в окремих проектах - принаймні за допомогою TestDriven.Net - є те, що я можу правою кнопкою миші натиснути на тестовий проект і запустити всі тести в цьому проекті, протестуючи всю бібліотеку коду програми одним клацанням миші.

Якщо використовується NUnit фреймворк, є додаткова причина для тестування в одному проекті. Розглянемо наступний приклад виробничого коду, змішаного з одиничними тестами:

public static class Ext
{
     [TestCase(1.1, Result = 1)]
     [TestCase(0.9, Result = 1)]
     public static int ToRoundedInt(this double d)
     {
         return (int) Math.Round(d);
     }
}

Одиничні тести тут служать документацією та специфікацією коду, який тестується. Я не знаю, як досягти цього ефекту самодокументування, з тестами, розташованими в окремому проекті. Користувачеві функції доведеться шукати тести, щоб побачити ті тестові випадки, що малоймовірно.

Оновлення : Я знаю, що таке використання TestCaseатрибуту було не те, що розробники NUnit мали намір, але чому б ні?

Я коливаюсь між одним і тим же проектом та різними проектами.

Якщо ви випускаєте бібліотеку, вивільнення тестового коду з виробничим кодом є проблемою, інакше я вважаю, що це зазвичай не так (хоча перед спробою є сильний психологічний бар'єр).

Під час тестування в одному проекті мені стає легше перемикатися між тестами та кодом, який вони перевіряють, і простіше переробляти / переміщувати їх.

Я розміщував їх в окремих проектах. Назва збірки відображає назву просторів імен, як загальне для нас правило. Отже, якщо є проект під назвою Company.Product.Feature.sln, він має вихід (назва збірки) Company.Product.Feature.dll. Тестовий проект - Company.Product.Feature.Tests.sln, поступаючись Company.Product.Feature.Tests.dll.

Найкраще зберігати їх в єдиному рішенні та контролювати висновок за допомогою Менеджера конфігурацій. У нас є названа конфігурація для кожної з основних галузей (Розвиток, Інтеграція, Виробництво) замість використання налагодження та випуску за замовчуванням. Після налаштування конфігурацій ви можете їх включити або виключити, натиснувши прапорець "Скласти" в Менеджері конфігурацій. (Щоб отримати Менеджер конфігурацій, клацніть правою кнопкою миші рішення та перейдіть до Менеджера конфігурацій.) Зауважте, що я знаходжу CM в Visual Studio часом помилковим. Пару разів мені довелося зайти в проект та / або файли рішення, щоб очистити цілі, які він створив.

Крім того, якщо ви використовуєте Team Build (і я впевнений, що інші інструменти збирання .NET такі самі), ви можете пов’язати збірку з іменованою конфігурацією. Це означає, що, якщо ви, наприклад, не будуєте тести на одиницю для своєї збірки "Виробництво", проект збірки може також знати про це налаштування, а не будувати їх, оскільки вони були позначені як такі.

Крім того, ми раніше робили краплі XCopy зі збірної машини. Сценарій просто пропускає копіювання будь-якого імені * .Tests.Dll від розгортання. Це було просто, але працювало.

Я б сказав, тримайте їх окремо.

На додаток до інших згаданих причин, з використанням коду та тестування разом, перекосуємо номери тесту на покриття. Коли ви повідомляєте про покриття тесту на одиницю - звітність охоплюється вище, оскільки тести покриваються під час запуску одиничних тестів. Коли ви повідомляєте про покриття тесту інтеграції, повідомлення про покриття є нижчим, оскільки тести інтеграції не виконуватимуть одиничні тести.

Мене дуже надихає блок тестування одиниць бібліотеки Flood NN Роберта Лопеса. Він використовує різний проект для кожного випробуваного класу одиниць і має одне рішення, що містить усі ці проекти, а також основний проект, який збирає та виконує всі тести.

Акуратною річчю є також макет проекту. Вихідні файли знаходяться в папці, але потім папка для проекту VS знаходиться нижче. Це дозволяє робити різні папки для різних компіляторів. Всі проекти VS поставляються з кодом, тому будь-хто дуже легко може виконати будь-який або всі тести одиниці.

Я знаю, що це дуже давнє запитання, але я хотів би додати свій досвід там. Нещодавно я змінив звичку одиничного тестування з окремих проектів на той самий.

Чому?

По-перше, я дуже прагну підтримувати структуру папки головного проекту однаковою з тестовим проектом. Отже, якщо у мене є файл, Providers > DataProvider > SqlDataProvider.csтоді я створюю таку ж структуру в своїх тестових проектах одиниць, якProviders > DataProvider > SqlDataProvider.Tests.cs

Але після того, як проект стає все більшим і більшим, коли ви переміщуєте файли з однієї папки в іншу або з одного проекту в інший, то над синхронізацією цих тестів з одиничними тестовими проектами стає дуже громіздка робота.

По-друге, не завжди дуже просто перейти від класу, який потрібно перевірити, до одиничного тестового класу. Це ще складніше для JavaScript та Python.

Нещодавно я почав практикувати, що кожен створений вами файл (наприклад SqlDataProvider.cs) я створюю ще один файл із суфіксом Test, наприкладSqlDataProvider.Tests.cs

На початку здається, що це роздує файли та посилання на бібліотеку, але в перспективі ви усунете синдром рухомих файлів на перший погляд, а також переконаєтесь, що кожен файл, який є кандидатом на тестування, матиме парний файл з .Testsсуфіксом. Це дозволяє вам легко перейти до тестового файлу (тому що він знаходиться поруч), а не переглядати окремий проект.

Ви навіть можете написати бізнес-правила, щоб просканувати проект та визначити клас, у якому немає файлу .Tests, та повідомити про це власнику. Крім того, ви можете сказати своєму тестовому бігуну легко орієнтуватися на .Testsкласи.

Спеціально для Js та Python вам не потрібно буде імпортувати свої посилання з іншого шляху, ви можете просто використовувати той самий шлях цільового файлу, який тестується.

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

Як відповіли інші - поставте тести в окремі проекти

Одне, що не було згадано, - це той факт, що ви насправді не можете працювати nunit3-console.exeпроти нічого, крім .dllфайлів.

Якщо ви плануєте запускати свої тести через TeamCity, це створить проблему.

Скажімо, у вас є проект консольного додатка. Коли ви компілюєте, він повертає виконуваний файл .exeу binпапку.

З цього nunit3-console.exeви не зможете запустити жодних тестів, визначених у цій консольній програмі.

Іншими словами, консольна програма повертає exeфайл, а бібліотека класів повертає dllфайли.

Я щойно покусав цим сьогодні, і це смокче :(

Я нещодавно розгортався в докер. Я не бачу значення в тому, щоб мати окремий проект, коли Dockerfile може легко скопіювати каталог / src та залишити каталог / test. Але я новачок у dotnet і, можливо, щось не вистачає.

Окремі проекти, хоча я дискутую сам із собою, чи повинні вони поділяти один і той же svn. На даний момент я даю їм окремі сховища svn, одне називається

"MyProject" - для самого проекту

і один подзвонив

"MyProjectTests" - для тестів, пов'язаних з MyProject.

Це досить чисто і має таку перевагу, яка бере на себе проект та зобов’язує тести зовсім окремо. Це також означає, що ви можете здати svn проекту, якщо це потрібно, без необхідності звільняти свої тести. Це також означає, що ви можете мати гілки / магістралі / теги каталогів для своїх тестів та для свого проекту.

Але я все більше схильний мати щось на зразок наступного, в одному сховищі svn, для кожного проекту.

MyProject
| \ Магістраль
| | \ Код
| \ Тести
| \ Теги
| | \ 0,1
| | | \ Код
| | \ Тести
| \ 0,2
| | \ Код
| \ Тести
\ Гілки
  \ MyFork
   | \ Код
    \ Тест

Мені було б цікаво дізнатися, що інші люди думають про це рішення.