a kód struktúrájából adódó minden lehetséges lefutási ág lefedésére törekszünk

csak integrációs tesztelés esetén lehetséges

Mésik neve a specifikáció alapú tesztelés

ez nem valódi tesztelés technika, csak a kód kézi próbálgatására vonatkozó zsargonkifejezés

Mert a változtatások története végigkövethető, korábbi állapotokra vissza lehet állni, és a párhuzamos kísérletezés külön ágakon elkülöníthető.

Mert a verziókezelő a munkakönyvtár minden fájlmentését automatikusan rögzíti, így a változtatásokat nem kell külön véglegesíteni.

Mert a verziókezelő minden véglegesítésnél lefuttatja a projekt tesztjeit, így hibás állapot nem kerülhet be a verziótörténetbe.

Mert a helyi tároló önmagában biztonsági mentésként is szolgál, így a projektről nem szükséges máshol másolatot tartani.

A hosszú életű ágon készült commitok a beolvasztáskor szükségszerűen egyetlen commitba olvadnak össze, így elvész a részletes változtatási történet.

Az ág egyre jobban eltávolodik a fő ágtól, így az integráció egyre nagyobb, nehezebben feloldható ütközésekkel jár.

Az ütközések feloldása összességében ugyanannyi munkát jelent, csak egyszerre, a beolvasztás pillanatában jelentkezik.

A hosszú életű ágon dolgozó fejlesztő nem tudja letölteni a többiek időközben végzett változtatásait, amíg a saját munkáját be nem olvasztotta.

Megkülönböztetünk specifikáció-alapú (black-box) és struktúra-alapú (white-box) tesztelési módszereket.

Célszerű a verifikációs és validációs (V&V) tevékenységeket minél később elvégezni a fejlesztés során, mert ez költséghatékonyabb.

Agilis életciklus modell esetén nem szokás tesztelni.

Statikus elemzés során a statikus változók viselkedését vizsgáljuk.

egységtesztelés (unit test)

integrációs teszt

statikus ellenőrzés

kockázatalapú tesztelés

fail

inconclusive

error

pass

fail

inconclusive

error

pass

Self-Updating Test

Simple Unit Test

Software-Undefined Type

System Under Test

Feature branching esetén a funkciókhoz külön, akár hosszú életű ágat használunk, trunk-based development esetén viszont egy közös ágon működünk együtt, hosszú életű ágak nélkül.

Trunk-based development esetén is minden funkcióhoz külön ág készül, a különbség csak annyi, hogy a beolvasztás gyakrabban történik.

Feature branching esetén a fejlesztők közösen a fő ágon dolgoznak, és csak a felülvizsgálatra szánt változtatást teszik át egy külön ágra.

A trunk-based development a feature branching pull request alapú változata, amelyben minden ágat felülvizsgálat után olvasztunk be.

A Make a fordítási lépéseket a projekt könyvtárszerkezetéből vezeti le, ezért nem kell hozzá külön leíró fájlt írni.

A Make kizárólag egyetlen programozási nyelven írt projektek fordítására alkalmas, több nyelvet használó projekthez Maven vagy Gradle szükséges.

A Make a projekt külső függőségeit a megadott verzióban automatikusan beszerzi, ezért azokat nem kell kézzel a projekt mellé másolni.

A Gradle inkrementális fordítást is kínál: felismeri, mely fordítási lépéseket nem kell újra végrehajtani, mert a bemenetük nem változott.