KISS elv a tesztautomatizálásban: miért fontosabb az olvasható kód, mint a túloptimalizálás?

A KISS elv a tesztautomatizálásban azért fontos, mert a jó tesztkódnak nem az a fő feladata, hogy minden apró részletében optimalizált legyen. Sokkal fontosabb, hogy a csapat gyorsan megértse, magabiztosan módosítsa, és hosszú távon is karbantartható állapotban tartsa a teszteket.

Sok tesztautomatizáló csapat belefut abba a hibába, hogy a rövidebb vagy „okosabb” kódot automatikusan jobb megoldásnak tekinti. Pedig a gyakorlatban az olvasható tesztkód gyakran többet ér, mint a túl tömör, nehezebben követhető megoldás.

Mit jelent a KISS a tesztautomatizálásban?

Ha valaki nem találkozott még vele: a KISS a „Keep It Simple, Stupid” rövidítése. Az elv lényege pedig, hogy nem érdemes bonyolultabb megközelítést választani akkor, ha egy egyszerűbb is jól, érthetően és stabilan elvégzi ugyanazt a feladatot. Ez nem a modernebb nyelvi eszközök elutasításáról szól, hanem arról, hogy csak akkor használjunk összetettebb megoldást, ha annak valódi előnye is van.

A tesztautomatizálásban ez különösen fontos, mert a tesztekhez jellemzően sokan nyúlnak hozzá: senior automatizálók, kezdőbb kollégák, manuális tesztelésből érkezők és új csapattagok is.

A túl tömör vagy túl „okos” tesztkód tipikus kockázatai:

• lassabb code review és több félreértés
• nehezebb onboarding új csapattagoknak
• nagyobb esély rossz módosításokra
• több rejtett technikai adósság a tesztautomatizálásban

Python példa a KISS elvre: for ciklus vs list comprehension

Pythonban gyakran előfordul, hogy ugyanazt a feladatot megírhatjuk több sorban, könnyebben követhető formában, vagy rövidebben, tömörebb szintaxissal is.

Egyszerűbb, kezdőbarátabb verzió:

failed_orders = []

for order in orders:
    if order["status"] == "failed":
        failed_orders.append(order)

Tömörebb, Pythonban gyakran használt verzió:

failed_orders = [order for order in orders if order["status"] == "failed"]

Mindkét megoldás helyes. A list comprehension rövidebb, sőt bizonyos helyzetekben gyorsabb is lehet. Azonban ha a csapat egy része még tanulja a Python-os gondolkodásmódot („pythonic”), az első verzióban tisztábban látszik a szándék és a lépések sorrendje.

A KISS elv a tesztautomatizálásban itt nem azt jelenti, hogy tilos a list comprehension. Inkább azt, hogy a kódstílust érdemes a csapat aktuális tudásszintjéhez és közös kódolvasási gyakorlatához igazítani.

TypeScript példa: explicit ellenőrzés vs nullish assignment

TypeScriptben hasonló helyzet előfordulhat egy PageManager osztályban is, amikor egy Page Object példányt csak akkor szeretnénk létrehozni, amikor először szükség van rá.

Részletesebb, könnyen követhető verzió:

class PageManager {
  private loginPage?: LoginPage;

  constructor(private readonly page: Page) {}

  getLoginPage(): LoginPage {
    if (this.loginPage) {
      return this.loginPage;
    }

    this.loginPage = new LoginPage(this.page);
    return this.loginPage;
  }
}

Rövidebb TypeScript-verzió nullish assignmenttel:

class PageManager {
  private loginPage?: LoginPage;

  constructor(private readonly page: Page) {}

  getLoginPage(): LoginPage {
    return (this.loginPage ??= new LoginPage(this.page));
  }
}

Mindkét megoldás ugyanazt a célt szolgálja. Ha a loginPage már létezik, akkor azt adjuk vissza, ha még nem, akkor létrehozzuk, eltároljuk, majd visszaadjuk.

A rövidebb verzió elegáns és teljesen korrekt TypeScriptben. Ugyanakkor egy vegyes senioritású csapatban az első verzió sokszor könnyebben értelmezhető, mert külön sorokban látszik az ellenőrzés, a példányosítás és a visszatérés.

A KISS elv itt sem azt jelenti, hogy kerülni kell a modernebb TypeScript nyelvi elemeket. Inkább azt, hogy a választott megoldás legyen arányos a csapat tudásával, a projekt komplexitásával és azzal, mennyire könnyen kell a kódot review során átnézni vagy hibakeresés közben értelmezni.

Miért fontosabb az olvasható tesztkód, mint a túloptimalizálás?

A jó tesztkód értéke nem abban van, hogy minél rövidebb, hanem abban, hogy érthető és hosszú távon karbantartható. Tesztautomatizálásban az értéket sokszor nem a minimálisan gyorsabb futás hozza, hanem az, hogy a csapat magabiztosan tudja olvasni, módosítani és továbbfejleszteni a teszteket.

A gyakorlatban ez azt jelenti, hogy:

• a közös kódolási irányelveket a csapat kompetenciaszintjéhez igazítjuk
• ugyanarra a problémára következetesen hasonló mintát használunk
• különbséget teszünk aközött, hogy mit lehet és mit érdemes használni

Ha a csapat 5-ből 4 tagja gyorsabban ért meg egy kicsit hosszabb kódot, akkor az gyakran jobb döntés, mint a rövidebb, de nehezebben olvasható megoldás.

Best practice-ek KISS mellett is

Az egyszerűség nem egyenlő az igénytelenséggel. A KISS elv a tesztautomatizálásban csak akkor működik jól, ha közben a fontos best practice-eket is betartjuk:

• beszédes függvény- és változónevek
• egyértelmű Arrange-Act-Assert (AAA) szerkezet a tesztekben
• duplikáció kerülése, de csak indokolt absztrakcióval
• stabil locator és megbízható wait stratégia UI tesztautomatizálásban
• kis, fókuszált helper függvények a mindent tudó utility blokkok helyett
• következetes code review szabályok és közös példák

Zárógondolat

A KISS elv a tesztautomatizálásban nem visszalépés, hanem tudatos szakmai döntés. A legtöbb csapat számára az érthető és könnyen módosítható tesztkód hozza a nagyobb értéket, nem a túlbonyolított rövidség.

Érdemes tehát először azt nézni, hogy a kód világos-e a csapat számára, és csak utána azt, hogy lehet-e még tovább tömöríteni. A jó tesztkód nem attól erős, hogy trükkös, hanem attól, hogy hosszú távon is működik.

Nálatok a tesztkódban mi élvez prioritást: a tömörség vagy a csapat szintjén is könnyen értelmezhető tesztkód?