Fogalomtár › Kód

tesztvezérelt fejlesztés (TDD)

angolul: test-driven development

Olyan programozási módszer, amelyben előbb megírják az ellenőrző tesztet, és csak utána azt a kódot, amelynek át kell mennie rajta.

Érthetően

Képzeld el, hogy egy tanár előbb megírja a dolgozat javítókulcsát, és csak utána kezdi el tanítani az anyagot. Így már az elején pontosan tudja, mit kell a végén tudnia a diáknak. A tesztvezérelt fejlesztés ugyanezt csinálja a szoftverrel: előbb rögzítik, mit jelent az, hogy „jól működik”, és csak utána írják meg magát a programot.

A teszt itt egy apró program, amely kipróbálja a készülő kódot, és megmondja, hogy azt csinálja-e, amit vártak tőle. Ha például egy webáruház kosarának 10 százalék kedvezményt kell adnia, a teszt beír egy összeget, és megnézi, hogy a végeredmény stimmel-e.

A szokásos sorrendhez képest ez fordított: a legtöbben előbb megírják a programot, és utólag próbálják ki. A TDD-ben a teszt a megrendelés, a kód pedig a teljesítés. Az AI korában ez azért lett újra fontos, mert a kódoló agent a tesztből egyértelműen látja, mikor van kész, és nem neki kell eldöntenie, hogy elég jó-e a munkája.

Hogyan működik

1. A fejlesztő (vagy a kódoló agent) megír egy rövid tesztet egyetlen apró elvárásra, például: „üres kosárnál a végösszeg nulla”.
2. Lefuttatja a tesztet, amely ilyenkor elbukik, hiszen a kód még nem létezik. Ez a „piros” állapot, és azt bizonyítja, hogy a teszt tényleg mér valamit.
3. Megírja a lehető legegyszerűbb kódot, amellyel a teszt átmegy. Ez a „zöld” állapot.
4. Rendbe teszi, átláthatóbbá alakítja a kódot úgy, hogy közben a tesztek végig zöldek maradnak. Ezt hívják refaktorálásnak.
5. Jön a következő apró elvárás, és a kör újraindul. A végére a tesztek sokasága védőhálót ad: ha egy későbbi módosítás elront valamit, azonnal kiderül.

Példa a mindennapokból

Kit érint

Gyakori félreértés

Korlátok és kockázatok

• A teszt is lehet hibás: ha rossz elvárást rögzít, a program pontosan a rossz dolgot fogja jól teljesíteni.
• A kódoló agent hajlamos lehet a tesztet átírni vagy a kódot a teszthez „hozzácsalni”, ahelyett hogy a feladatot oldaná meg, ezért érdemes megtiltani neki a tesztek módosítását és átnézni a végeredményt.
• Az elején több idő megy el vele, és a megtérülése csak később, a karbantartásnál látszik.
• Nehezen alkalmazható ott, ahol az eredmény nem írható le egyértelmű elvárással, például a látvány, a felhasználói élmény vagy egy AI-modell változó válaszai esetén.

Hasonló, de nem ugyanaz

• szoftvertesztelés – A tesztelés általában a kész programot ellenőrzi utólag, a TDD-ben viszont a teszt készül el előbb, és az szabja meg, milyen kód születik.
• vibe coding – A vibe coding során érzésre, a kód ellenőrzése nélkül fogadod el, amit az AI ír, a TDD ezzel szemben minden lépést előre rögzített ellenőrzéshez köt.
• viselkedésvezérelt fejlesztés (BDD) – A BDD a TDD-ből nőtt ki, de az elvárásokat hétköznapi nyelven, a felhasználó szemszögéből írja le, hogy az üzleti oldal is értse.

Kapcsolódó fogalmak

Röviden a története

A módszert Kent Beck amerikai szoftverfejlesztő tette ismertté az extrém programozás részeként, majd a 2002-ben megjelent Test-Driven Development: By Example című könyvében írta le részletesen. Ő maga úgy fogalmazott, hogy nem feltalálta, hanem „újra felfedezte” a régi gyakorlatot.

Hol tart most

A szoftveriparban régóta ismert, bár nem mindenhol következetesen alkalmazott módszer. 2026 végére a kódoló agentek miatt új lendületet kapott, mert a teszt az egyik legmegbízhatóbb módja annak, hogy az agent munkáját automatikusan ellenőrizni lehessen.

Állapot: 2026. november

Más nevei

TDD · tesztvezérelt fejlesztés · teszt-vezérelt fejlesztés · tesztvezérelt programozás · test-driven development · test driven development · test-first fejlesztés · red-green-refactor

Források

• Wikipédia: Test-driven development
• Martin Fowler: Test Driven Development

A szócikk gépi szerkesztéssel készült és gépi szakmai lektoráláson ment át; a „hírekben” rész az Agent Age sztorijaiból automatikusan frissül.