що є відповідним способом написання JunitTestCases для цього методу - тестування одиниць, тестування, Джуніт

Наведений нижче код - це моя логіка методу.

pulic String getData()
{
if (leg.length == 4)
return "ATE";
else  if (leg.length == 2) {
return "FTE";
}
if (leg.length == 3) {
if (xr1.KotilaType.equals("CST")) {
return "HTE";
}
return "DTE";
}
return "BTE";
}

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

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

Тепер моє запитання: Чи потрібно нам писати окремий випробувальний випадок Junit (окремий метод) для кожної умови ??

Або буде достатньо написати лише One Junit TestCase та охопити всі вищезазначені умови ??

Я новачок у junit, а не фахівець. Будь ласка, скеруйте мене, який відповідний спосіб написання JunitTestCases для вищевказаного методу ??

Відповіді:

Це питання стилю. Це дві альтернативи: з використанням одного методу:

public void testAll() {
assertEquals("ATE", getData(leg4));
assertEquals("FTE", getData(leg2));
// etc.
}

За допомогою одного методу / комбінації випробувань:

public void testLength4() {
assertEquals("ATE", getData(leg4));
}

public void testLength2() {
assertEquals("FTE", getData(leg2));
}

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

Останній має ту перевагу, що у вас єтестувати на комбінацію, тому локалізувати проблему дуже просто, оскільки (теоретично) не вдасться виконати лише один тест. Недолік: у вас дуже швидко закінчуються імена для методів тестування. testLength4, testLength2, testLength3WithCST, testLength3WithoutCST. Цей недолік отримує особливо погано, коли у вас багато комбінацій (скажімо, як один тест на кожен місяць у році).

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

Я б розпочав з п’яти одиничних тестів для кожного можливого поверненого значення, встановивши стан об’єкта, що перевіряється (leg.length & xr1.KotilaType), на відповідні значення в кожному тесті.

Потім я перейшов до тестів, які охоплювали граничні значення, наприклад leg.length == 5, 1 тощо.