Чи слід зберігати одиничні тести у сховищі?

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

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

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

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

Проте код тесту повинен бути добре відокремлений від виробничого коду. Наприклад, Maven досягає цього, розміщуючи виробничий та тестовий код у різні папки. Питання "це файлова частина виробництва або тестового коду" ніколи не виникає.

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

Якщо ви не включите одиничні тести у зареєстрований вихідний код, тоді:

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

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

Звичайно, ви повинні помістити одиничні тести в сховище з кількох причин:

• легко повернутися до попередньої версії
• інші люди, що працюють над проектом, також отримують доступ до тестувань
• деякі люди розглядають одиничні тести як частину документації (TDD та BDD)

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

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

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

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

Я щойно закінчив читати "Розвиток додатків Браунфілда в .Net" , і це дає чудові поради щодо структури програми, включаючи управління джерелами та де / як / навіщо включати тести для одиниць (особливо в області постійної інтеграції) . Якщо ви розробник .Net, я б рекомендував це.