Стендап Сьогодні 📢 Канал в Telegram @stendap_sogodni

🤖🚫 Контент вільний від AI. Цей пост на 100% написаний людиною, як і все на моєму блозі. Насолоджуйтесь!

03.06.2024

Тести на покриття коду (особливо на Ruby)

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

• Результати з паралельних тестів ще треба обʼєднати. На те є довга інструкція; код писати доведеться, власним поділитися не можу, але скажу, що інструкція все пояснює.

• На покриття потрібно дивитися файл за файлом. Інтегративна оцінка є “середньою температурою по палаті”, та головне — не повідомить про додавання нового непокритого коду — бо один пакет змін не зсуне суттєво покриття проєкту. А це задача №1 - уникнути написання коду без тестів.

• Який відсоток покриття вважати гарним? Я спочатку намагався зробити хитро та перевіряти не фіксований відсоток, а інваріант “кожна зміна покращує покриття.” Мета була — уникнути явних виключень файлів з низьким покриттям з перевірки. Проте це виявилося ну дуже нестабільним в реаліях проєкту з багатьма гілками та паралельною розробкою. Тому зараз порогом є 90% покриття рядків та 80% покриття гілок… та все ж з набором файлів-виключень.

• Про покриття гілок. Його часто складно досягнути, бо потрібно покрити кожну гілку обробки помилок. (В Go взагалі не уявляю як це.) З іншого боку… код ми написали, а запускати не плануємо? То може його прибрати чи замінити на узагальнений варіант?

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