Що має бути першим: тестування чи перегляд коду?

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

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

Який підхід рекомендується і чому?

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

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

В ідеалі в Agile світі обидва :)

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

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

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

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

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

Перевірте спочатку. Тест останній. Тест, тест, тест.

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

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

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

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

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

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

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

Що по-перше, яйце чи курка?
Це залежить.

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

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

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

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

Тільки два мої копійки.

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

• Проектні перевірки
• Кодові перевірки
• Одиничні тести
• Нові функціональні тести
• Регресійні тести
• Тести на продуктивність
• Системні тести
• Зовнішні бета-тести

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