Мені цікаво, чи вимірювання покриття умовного коду поточними інструментами для Java не застаріло з моменту появи Java 8. Завдяки Java 8 Optionalі Streamми часто можемо уникати гілок / циклів коду, що дозволяє легко отримати дуже високе умовне покриття без тестування всіх можливих шляхів виконання. Порівняємо старий код Java з кодом Java 8:
Перед Java 8:
public String getName(User user) {
if (user != null) {
if (user.getName() != null) {
return user.getName();
}
}
return "unknown";
}
У вищеописаному способі є 3 можливих шляхи виконання. Для отримання 100% умовного покриття нам потрібно створити 3 одиничні тести.
Java 8:
public String getName(User user) {
return Optional.ofNullable(user)
.map(User::getName)
.orElse("unknown");
}
У цьому випадку гілки приховані, і нам потрібен лише 1 тест, щоб отримати 100% охоплення, і не має значення, у якому випадку ми будемо перевіряти. Хоча я вважаю, що все ще є ті ж 3 логічні гілки, які слід висвітлити. Я думаю, що це робить статистику умовного покриття цілком недовіреною в наші дні.
Чи є сенс вимірювати умовне покриття коду Java 8? Чи є якісь інші інструменти, які визначають недооцінений код?
getName? Здається, що якщо userнуль, він повинен повернути "невідомо". Якщо userне є null і user.getName()є null, він повинен повернути "unknown". Якщо userце не null і user.getName()не null, він повинен повернути це. Таким чином, ви б провели тестування цих трьох випадків, оскільки саме про це укладається контракт getName. Ви, здається, робите це назад. Ви не хочете бачити філії та писати тести відповідно до цих, ви хочете писати свої тести відповідно до свого контракту та стежити за тим, щоб контракт був заповнений. Ось тоді ви маєте гарне покриття.