Чи слід проводити перевірку коду до або після тестових одиниць

10

Я обговорюю з колегою питання про те, коли пройти перевірку коду - до або після тестування одиниць. Яка найкраща практика?

Деякі фактори, які нам можуть знадобитися враховувати (їх може бути більше):

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

language-agnostic code-reviews

— димба
джерело

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

— Ллойд Пауелл

20

Ви завжди повинні проводити тестування, перш ніж робити перевірку коду, і ось чому

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

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

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

— Брайан Андерсон
джерело

11

Огляди коду - це коли код "зроблено".

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

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

— Ніл Томпсон
джерело

Чи не має сенсу робити перегляд коду на код, перш ніж писати на нього одиничні тести?

— dimba

якщо у вас є тести, і огляд коду пропонує зміни в код, ви можете внести зміни до коду з упевненістю, оскільки вони підтримуються тестами. Без тестів зміни в результаті перегляду коду можуть ввести помилки.

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

— dimba

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

4

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

Також слід перевірити тести. Це критично важливо для тих, хто не знайомий з тестовими одиницями.

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

Вам не потрібно реалізовувати вищезазначені теми, але ви повинні їх зрозуміти.

— Скотс Коутс
джерело

2

Добре,

Це залежить від того, що ви маєте на увазі під "тестовою одиницею" ...

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

І

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

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

Чому ми робимо перегляд коду? Щодо якості коду ... Замість воріт "контролю якості" введіть якість у ваш процес розробки програмного забезпечення ...

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

— dimba

2

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

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

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

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

— арсенал
джерело