Към съдържанието
wannacode

Тестовете като предпазна мрежа

Накратко: Характеризиращите тестове (characterization tests) заковават какво прави старият код днес, затова хващат всяка неволна промяна на поведението, докато го подреждаш.

Проблем

Безобидната промяна

Магазинът смята доставката с метода Delivery.fee. Писана е преди три години, тестове няма. Доставката е 4,50 €, извън София е с 2 € повече, до Видин с още 3 €, а над 10 кг се плаща по 0,50 € за всеки килограм отгоре. От 50 € нагоре е безплатна.

class Delivery {
static double fee(double total, int kg, String city) {
double fee = 4.50;
if (!city.equals("София")) {
fee = fee + 2.00;
}
if (city.equals("Видин")) {
fee = fee + 3.00;
}
if (kg > 10) {
fee = fee + (kg - 10) * 0.50;
}
if (total >= 50) {
fee = 0;
}
return fee;
}
}

Миналия месец колега я „подреди“: щом поръчката е безплатна, защо да смятаме, и премести проверката най-отгоре. Написа total > 50 вместо total >= 50. Цяла седмица поръчките за точно 50 € плащаха доставка. Никой не забеляза, докато не дойдоха оплакванията.

Сега на теб ти трябва да добавиш нов град. Пипаш ли този метод? Ако не я пипаш, всяко ново правило се лепи отгоре и кодът става все по-страшен. Ако я пипаш, може да счупиш нещо, което работи, и да не разбереш.

Идеята

Мрежа под въжето

Въжеиграчът върви по въжето спокойно, защото отдолу има мрежа. Ако падне, мрежата го хваща, преди да стане беля.

За кода мрежата са тестовете. Преди да смениш как е написан кодът, пишеш тестове, които казват какво прави той днес. После сменяш и пускаш тестовете. Зелено: поведението е същото. Червено: нещо се е сменило, и знаеш точно кое.

Такива тестове се казват характеризиращи (characterization tests): те не проверяват дали кодът е верен, а описват как се държи. Ако днес кодът прави нещо странно, тестът записва и странното. Това е предпазната мрежа: никакъв код не се пипа, докато под него няма тестове.

Виж го

Запиши какво прави днес

Не гадаеш какво би трябвало да връща методът. Питаш него. Една кратка програма я вика с няколко поръчки и печата отговорите:

System.out.println("20 €, 2 кг, София → " + Delivery.fee(20, 2, "София"));
System.out.println("20 €, 2 кг, Пловдив → " + Delivery.fee(20, 2, "Пловдив"));
System.out.println("20 €, 16 кг, София → " + Delivery.fee(20, 16, "София"));
System.out.println("50 €, 2 кг, Пловдив → " + Delivery.fee(50, 2, "Пловдив"));
System.out.println("60 €, 25 кг, Пловдив → " + Delivery.fee(60, 25, "Пловдив"));
Изход
20 €, 2 кг, София → 4.5
20 €, 2 кг, Пловдив → 6.5
20 €, 16 кг, София → 7.5
50 €, 2 кг, Пловдив → 0.0
60 €, 25 кг, Пловдив → 0.0

Последният ред е изненада. Пакетът е 25 кг, а доставката е безплатна: безплатната доставка маха и надценката за тегло. Грешка ли е? Може би. Но днес е така, клиентите го ползват, и решението дали да се смени не е твое, докато подреждаш кода. Записваш го такова, каквото е.

Всеки ред от пробата става тест:

import org.junit.jupiter.api.Test;
import static org.junit.jupiter.api.Assertions.assertEquals;
class DeliveryTest {
@Test
void sofia() {
assertEquals(4.5, Delivery.fee(20, 2, "София"));
}
@Test
void outsideSofia() {
assertEquals(6.5, Delivery.fee(20, 2, "Пловдив"));
}
@Test
void heavy() {
assertEquals(7.5, Delivery.fee(20, 16, "София"));
}
@Test
void freeFrom50() {
assertEquals(0.0, Delivery.fee(50, 2, "Пловдив"));
}
@Test
void freeEvenWhenHeavy() {
// Така е днес: безплатната доставка маха и надценката за тегло.
assertEquals(0.0, Delivery.fee(60, 25, "Пловдив"));
}
}
Резултат
ОК freeEvenWhenHeavy()
ОК freeFrom50()
ОК heavy()
ОК outsideSofia()
ОК sofia()
Тестове: 5, минали: 5, паднали: 0

Пет теста, пет зелени. Мрежата е опъната.

По-точно, за любопитните

Тестовете тук се пускат както в урока за тестовете от модул „Програми в истинския свят“. Проверената програма слага класа и теста в един файл и пуска JUnit 5 през Launcher API, като подрежда резултатите по име. Така изходът е един и същ при всяко пускане.

Стойностите в теста са каквото Java отпечата. 4.5 и 0.0 са double, а сумите тук са кратни на 0,50 и се пазят точно, затова assertEquals без допустима разлика стига.

Виж го

Безобидната промяна под мрежата

Сега колегата прави същата промяна, но под мрежа. Проверката отива най-отгоре:

class Delivery {
static double fee(double total, int kg, String city) {
if (total > 50) {
return 0;
}
double fee = 4.50;
if (!city.equals("София")) {
fee = fee + 2.00;
}
if (city.equals("Видин")) {
fee = fee + 3.00;
}
if (kg > 10) {
fee = fee + (kg - 10) * 0.50;
}
return fee;
}
}
Резултат
ОК freeEvenWhenHeavy()
ОК heavy()
ОК outsideSofia()
ОК sofia()
ПАДА freeFrom50(): expected: <0.0> but was: <6.5>
Тестове: 5, минали: 4, паднали: 1

Един тест е червен и казва точно кой случай: поръчка за 50 € извън София. Очаквано 0, а е 6,50 €. Грешката е хваната на бюрото, не от клиент.

class DeliveryTest {
@Test
void sofia() {
assertEquals(4.5, Delivery.fee(20, 2, "София"));
}
@Test
void outsideSofia() {
assertEquals(6.5, Delivery.fee(20, 2, "Пловдив"));
}
@Test
void heavy() {
assertEquals(7.5, Delivery.fee(20, 16, "София"));
}
@Test
void freeFrom50() {
assertEquals(0.0, Delivery.fee(50, 2, "Пловдив"));
}
@Test
void freeEvenWhenHeavy() {
// Така е днес: безплатната доставка маха и надценката за тегло.
assertEquals(0.0, Delivery.fee(60, 25, "Пловдив"));
}
}
Стъпка по стъпка, с думи
  1. Пет теста, по един за всеки ред от пробата. Всеки вика Delivery.fee и сравнява с отговора, който дава днес.
  2. Delivery.fee(20, 2, "София") връща 4.5. Тестът го заковава.
  3. Delivery.fee(20, 2, "Пловдив") връща 6.5. Тестът го заковава.
  4. Delivery.fee(20, 16, "София") връща 7.5. Тестът го заковава.
  5. Delivery.fee(50, 2, "Пловдив") връща 0.0. Тестът го заковава.
  6. Delivery.fee(60, 25, "Пловдив") връща 0.0, макар пакетът да е 25 кг. Странно, но днес е така: тестът го пази, не го поправя.
  7. Колегата мести проверката за безплатна доставка най-отгоре и пише > вместо >=. Мрежата се пуска цялата.
  8. freeFrom50() пада: очаквано 0.0, а е 6.5. Поръчка за точно 50 € вече плаща доставка.
  9. С >= петте теста са зелени. Промяната е безопасна: мрежата я провери.

С >= всичко е зелено:

class Delivery {
static double fee(double total, int kg, String city) {
if (total >= 50) {
return 0;
}
double fee = 4.50;
if (!city.equals("София")) {
fee = fee + 2.00;
}
if (city.equals("Видин")) {
fee = fee + 3.00;
}
if (kg > 10) {
fee = fee + (kg - 10) * 0.50;
}
return fee;
}
}
Резултат
ОК freeEvenWhenHeavy()
ОК freeFrom50()
ОК heavy()
ОК outsideSofia()
ОК sofia()
Тестове: 5, минали: 5, паднали: 0

Промяната е същата като онази, която мина незабелязано цяла седмица. Разликата е само мрежата.

Пробвай

Предвиди изхода

Някой сменя реда за надценката за тегло и забравя да извади първите 10 кг:

fee = fee + kg * 0.50;

Тестовете от картата „Запиши какво прави днес“ се пускат пак. Какво става?

class Delivery {
static double fee(double total, int kg, String city) {
double fee = 4.50;
if (!city.equals("София")) {
fee = fee + 2.00;
}
if (city.equals("Видин")) {
fee = fee + 3.00;
}
if (kg > 10) {
fee = fee + kg * 0.50;
}
if (total >= 50) {
fee = 0;
}
return fee;
}
}
Отговор

Пробвай

Какво пишеш като очаквано

Пробата отпечата за 60 €, 25 кг и Пловдив: 0.0. Ти си сигурен, че правилната доставка е 14 €. Какво пишеш в теста преди промяната?

@Test
void freeEvenWhenHeavy() {
    assertEquals(, Delivery.fee(60, 25, "Пловдив"));
}

Идеята

Малки стъпки

Мрежата помага най-много, когато падаш от ниско. Ако смениш двадесет неща наведнъж и един тест падне, не знаеш кое от двадесетте е виновно. Ако смениш едно и тестът падне, виновникът е ясен.

Затова се работи в ритъм: една малка промяна, пускаш тестовете, зелено, следващата. Червено значи: върни последната промяна (Ctrl+Z или git checkout на файла) и я направи на още по-малки парчета. Така кодът почти през цялото време е в състояние, което работи.

Подреди стъпките:

  1. Направи една малка промяна
  2. Пусни тестовете пак
  3. Пусни тестовете: всички са зелени
  4. Добави тестове за пътя, който ще пипаш
  5. Зелено: запази (commit). Червено: върни само последната промяна

Пробвай

Намери грешката

Някой е написал теста за 50 € така. После колегата прави промяната с total > 50 от картата „Безобидната промяна под мрежата“:

class DeliveryTest {
@Test
void sofia() {
assertEquals(4.5, Delivery.fee(20, 2, "София"));
}
@Test
void outsideSofia() {
assertEquals(6.5, Delivery.fee(20, 2, "Пловдив"));
}
@Test
void heavy() {
assertEquals(7.5, Delivery.fee(20, 16, "София"));
}
@Test
void freeFrom50() {
System.out.println(Delivery.fee(50, 2, "Пловдив"));
}
@Test
void freeEvenWhenHeavy() {
// Така е днес: безплатната доставка маха и надценката за тегло.
assertEquals(0.0, Delivery.fee(60, 25, "Пловдив"));
}
}
Резултат
6.5
ОК freeEvenWhenHeavy()
ОК freeFrom50()
ОК heavy()
ОК outsideSofia()
ОК sofia()
Тестове: 5, минали: 5, паднали: 0

Грешната сума е отпечатана, а тестовете са зелени. На кой ред е грешката?

Избери реда с грешката.

Идеята

Какво мрежата не хваща

Мрежата хваща само там, където е опъната. За Видин тест няма. Някой „подрежда“ градовете с else if:

class Delivery {
static double fee(double total, int kg, String city) {
double fee = 4.50;
if (city.equals("Видин")) {
fee = fee + 3.00;
} else if (!city.equals("София")) {
fee = fee + 2.00;
}
if (kg > 10) {
fee = fee + (kg - 10) * 0.50;
}
if (total >= 50) {
fee = 0;
}
return fee;
}
}
Тестовете
ОК freeEvenWhenHeavy()
ОК freeFrom50()
ОК heavy()
ОК outsideSofia()
ОК sofia()
Тестове: 5, минали: 5, паднали: 0
Видин преди и след
Видин преди: 9.5
Видин след: 7.5

Тестовете са зелени, а доставката до Видин поевтиня с 2 €: преди Видин плащаше и 2 € извън София, и 3 € отгоре. Никой тест не минава през този път, затова никой не пада.

Преди да пипнеш код, виж кои пътища имат тестове и добави за тези, които ще пипаш. Това показва покритието (coverage): кои редове са минали при пускането на тестовете.

В IntelliJ IDEA тестовете се пускат с „Run with Coverage“ и редовете без тест светват в червено. В проект с Maven или Gradle същото дава JaCoCo.Едно нещо обаче компилаторът пази и без тест. Ако преименуваш fee на ръка и го забравиш в клона за Видин, програмата не се компилира: fee вече не съществува. Грешката е намерена, преди да има тест.
По-точно, за любопитните

Покритие 100% не значи, че всеки случай е проверен. Редът с total >= 50 е „покрит“ и от тест с 60 €, но точно 50 € е отделен случай, и само тестът за 50 € хваща >. Покритието казва къде мрежата има дупки. Колко е гъста там, където я има, зависи от случаите, които си избрал: границите (50 €, 10 кг), всеки клон на if и странните стойности от пробата.

Командите за покритие тук не се пускат: проверката на сайта е без мрежа и без външни пакети.

Упражнение

Мрежа за Видин

Реши задачата в редактора си.

Мрежа за Видин. Добави два теста към тестовете от картата „Запиши какво прави днес“: поръчка за 20 €, 2 кг до Видин и поръчка за 50 €, 2 кг до Видин. Първо пусни пробата, за да видиш какво връща кодът днес, и закови това.

Резултат
ОК freeEvenWhenHeavy()
ОК freeFrom50()
ОК heavy()
ОК outsideSofia()
ОК sofia()
ОК vidin()
ОК vidinFreeFrom50()
Тестове: 7, минали: 7, паднали: 0

После направи промяната с else if от картата „Какво мрежата не хваща“. Сега тя трябва да падне:

Резултат
ОК freeEvenWhenHeavy()
ОК freeFrom50()
ОК heavy()
ОК outsideSofia()
ОК sofia()
ОК vidinFreeFrom50()
ПАДА vidin(): expected: <9.5> but was: <7.5>
Тестове: 7, минали: 6, паднали: 1

Още задачи

  • Границата на теглото. Добави тест за точно 10 кг и за 11 кг. После смени kg > 10 на kg >= 10. Пада ли нещо? Защо?
  • Новият град. Добави Варна с 1 € отгоре. Първо тест за Варна, който пада, после правилото, после пак всички тестове.
  • Проба за всичко. Напиши пробата с цикъл по таблица от случаи (сума, тегло, град), така че нов случай да е нов ред в таблицата.

Тест

Провери се

1. Пробата показва, че поръчка за 60 € с пакет от 25 кг се доставя безплатно. Според теб това е грешка. Какво пишеш в теста преди промяната?
2. Пет теста минават. Пренареждаш функцията и един пада. Какво правиш?
3. Защо стъпките са малки и тестовете се пускат след всяка?
4. Всички тестове са зелени. Значи ли това, че промяната не е сменила нищо?
5. Тест вика функцията и печата резултата, без да го сравнява. Какво пази той?

Създаден от Иво Гергов като част от кампанията на Evo Tech за достъпно обучение по програмиране ·