Чи є TDD життєздатним у спільних проектах з відкритим кодом

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

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

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

open-source tdd collaboration

— DormoTheNord
джерело

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

— ґнат

@gnat Я шукав StackExchange, і було декілька питань, де люди задають приклади проектів з відкритим кодом з тестовими одиницями, що не те саме, що моє питання. Відповідно до вашого запиту, я додав ще трохи інформації.

— DormoTheNord

DormoTheNord Я вважаю, @gnat мав на увазі конкретні, цитовані приклади.

— haneefmubarak

"було б краще просто написати функцію / помилку". З тестами чи без них? Ви прихильник TDD чи просто перевіряєте, чи є він життєздатним у цьому контексті?

— JeffO

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

— Бенджамін Грюнбаум

Відповіді:

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

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

Це не гарантує , що тест написаний перший , але гарантує , що тест написаний .

— Барт ван Інген Шенау
джерело

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

— Том Ш

@TomW: Як би ви перевірили, чи моє подання створено відповідно до практики TDD, а не, наприклад, з тестами, написаними після впровадження?

— Барт ван Інген Шенау

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

— Том Ш

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

— Адріан Шнайдер

Ви можете попросити людей надіслати виправлення лише для тесту, перш ніж їм працювати над кодом; це дало б додаткову можливість переглянути запланований дизайн до того, як буде написаний сам код.

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

Однак рецензенти повинні були б дуже добре розгортати огляди дизайну, щоб не зупинити розробку.

— Алекс Фейнман
джерело