Спритний без одиничних тестів

Чи має сенс говорити про "спритний розвиток" або стверджувати, що ви застосовуєте "спритну методологію", якщо база коду, над якою ви працюєте, має 0% тестового покриття? (І ви, як команда, нічого не робите з цього приводу).

Щоб було зрозуміло: для мене це не має сенсу. На моєму особистому досвіді я виявив, що одиничні тести - це єдиний інструмент, який дозволяє реально бути "спритними" (тобто реагувати на зміни, вдосконалювати дизайн, ділитися знаннями тощо), а TDD - це єдина практика, яка веде вас туди .

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

Щоб бути педантичним, ніщо в Agile Manifesto або Посібнику з Scrum взагалі не посилається на технічні практики, такі як тестування блоків або TDD. Так, так, теоретично ви могли б поставити рано і часто, зосереджуючись на співпраці та вартості без них і називати себе Agile, ви навіть можете насправді спритність .

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

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

Швидкий маніфест просто говорить:

Індивіди та взаємодія над процесами та інструментами

Працює програмне забезпечення над всеосяжною документацією

Співпраця з клієнтами щодо укладання договорів

Відповідаючи на зміни протягом наступного плану

Ніяких згадок про одиничні тести там немає. Навіть 12 принципів не згадують про тестування.

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

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

Працює програмне забезпечення  над всеосяжною документацією.

Як би хтось знав, чи працює програмне забезпечення? У маніфесті не слід чітко вказувати термін тестування. Це лаконічно.

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

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

Ні, вам взагалі не потрібно тестування.

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

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

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

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

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

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

Я хотів би протиставити аргументацію (інші відповіді), що маніфест Agile чітко говорить про це, а саме:

Постійна увага до технічної досконалості та гарного дизайну підвищує спритність.

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

Організаційна спритність обмежена технічною спритністю

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

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

Я винайшов Екстремальне програмування, щоб зробити світ безпечним для програмістів. - Кент Бек

Scrum бракує будь-яких технічних практик, але Джефф сказав про це наступне:

Я ніколи не бачив надвиробничої команди Scrum, яка не використовувала практику розробки Extreme Programming. - Джефф Сазерленд

Цитується з цієї статті: http://ronjeffries.com/articles/017-02ff/gathering2017/

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

Модель Agile fluence згадує її на рівні двох зірок:

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

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

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

Як ви думаєте, що відповідь буде, якщо ми запитаємо деяких підписантів маніфесту, як Роберт К. Мартін, Мартін Фаулер чи Кент Бек? Можливо, вони скажуть, що це залежить, але, як правило, це потрібно зробити.