Моя колега придумала ідею, яку мені здалося цікавою.

Чи не було б вигідно писати тести під час перегляду коду особою, яка проводить огляд, припускаючи, що ми не робимо TDD?

Для цього питання припустимо, що це суто академічний проект, тому життя не загрожує. Більше того, команда - 4 людини. Усі знають мову та знайомі з усіма використовуваними інструментами / бібліотеками / рамками та можуть писати тести. Тому в основному люди, які не є старшими на fullstack, ведуть інженерів-ніндзя, але пристойних кодерів.

Плюси, які я знайшов:

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

Мінуси я знайшов:

1. Зростає цикл зворотного зв'язку між написанням коду та тестуванням.

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

Чи не було б вигідно писати тести під час перегляду коду особою, яка проводить огляд?

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

Переключення завдань для комп’ютерів коштує дорого - тим більше для людини.

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

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

Якщо припустити, що ми не робимо TDD?

Навіть якщо ви практикуєте TDD, якщо ви розумієте, що вам потрібен тест під час перегляду коду, такого, якого у вас немає, чому б не написати тест тоді і там?

Плюси

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

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

Коваджі

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

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

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

Це все виграші в моїй книзі.

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

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

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

Я погоджуюся з відповіддю @ RobbieDee, але у мене є ще трохи додати.

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

Це зробило б те ж саме, все-таки тримати зворотній зв'язок короткий і змусити всіх обговорити історію, що, на мою думку, було б кориснішим.

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

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

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

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

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

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

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

З іншого боку, я рекомендую НЕ ПОТРІБИТИСЯ з тестами / кодом під час огляду. Спробуйте щось зламати. Прокоментуйте умову if. замініть булеве значення буквальним true / false. Подивіться, чи не піддаються тести.

Але так, загалом, я рекомендую написати свої тести разом зі своїм кодом, а потім переглянути їх відразу.

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

• по-перше, якщо ви також рефакторинг під час перегляду коду, і зазначаєте, що недостатньо одиничних тестів для покриття виду рефакторингу, який ви хочете застосувати, додайте такі тести

• по-друге, якщо код на вас виглядає так, як ніби він може мати помилку, і ви хочете, щоб він це довів (або спростував), напишіть на нього тест

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

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

Ні, не робіть цього. Ви змусите їх думати, що TDD - жахливий.

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

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

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

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

Одиничні тести під час перегляду коду є поганою заміною одиничних тестів під час розробки.

Те, що ви пропонуєте, має багато сенсу, інтуїтивно. Який огляд? Щоб перевірити, чи добре код. Для чого призначені тести? Щоб перевірити, чи добре код. То чому б не поєднати два?

Ось чому.

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

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

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

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

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

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

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

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

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

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

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

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

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

Огляд - чудовий час для виявлення кутових справ. І якщо рецензент може зайти і написати тест на кутові справи, які вона знайде, то ей - ще краще! Але взагалі кажучи, якщо припустити, що рецензент може писати тести, де розробник не звучить як дуже погана ідея.