Конкурс тестування одиниць

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

Ми присвоювали бали для кожного тестового випадку. Тож якщо ви написали одиничний тест так ...

for (int i = 0; i < 100; i++) {
  assertTrue(i*i, square(i));
}

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

Ми насамперед магазин Java та Javascript. Тому я запропонував підрахувати кількість гілок коду, перевірених як метрику. Ми можемо легко підрахувати випробувані гілки за допомогою інструменту покриття коду (наприклад, EclEmma). Однак не впевнений, як би ми це зробили за допомогою наших тестів Selenium та отримання кодового покриття на джерелах Javascript (будь-які ідеї?)

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

Редагувати

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

Редагувати

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

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

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

Як бонус, ви отримаєте перевірку всіх своїх тестів.

Тож якщо ви написали одиничний тест так ...

for (int i = 0; i < 100; i++) {
 assertTrue(i*i, square(i));
}

вам дадуть 100 балів.

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

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

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

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

1. Використовуйте парні огляди для тестів і мають щось подібне до показника кількості WTF за хвилину .

2. Виміряйте вплив цих тестів у часі на кількість помилок . Це має ряд переваг:

   • Здається, справедливо,
   • Дійсно можна виміряти, якщо ви збираєте достатньо даних про звіти про помилки та їх долю,
   • Насправді варто!

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

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

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

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

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

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

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