"Csak jó kódot kell írni"

Tegnap írtam egy nem túl bonyolult Buildert. Van egy default lista, amire fel lehet vinni valamilyen megszorításokat, meg még egy bizonyos kulcs alapján lehet definiálni további megszorításokat, vagy az alaplistából kivenni feloldásokat. Jó, ennél egy fél fokkal bonyolultabb a szitu, de azért mégsem atomtechnika.

Ma írtam hozzá unit teszteket is. Eredmény? Vagy 5-6 elgépelés és egy végig nem godolt eset derült ki, közben meg született is 14 teszt ehhez a kódhoz. Ráadásul mikor a korábban végig nem gondolt esetet megoldó kódot implementáltam sikerült elrontani egy másik helyen, amit már a korábbi tesztek írásakor jónak minősítettem. Így egyből kiderült, hogy nem lesz minden jó.

Na, ezért kellenek rendes unit és integrációs tesztek. Néha még a triviális dolgokra is, mert ki tudja, hogy később nem lesz-e belőle kevésbé triviális, amit már senki nem fog kézzel tesztelni.

( MrSealRD v | 2018. 05. 31., cs – 16:10 )

Csak kérdezem. Nem az lett volna a jó irány, hogy előbb Unit tesztek, és utána kód?

( uid_6201 v | 2018. 05. 31., cs – 17:25 )

A testing (unit, integration) igen jelentős változáson ment át 2 évtized alatt, amióta Linux parancssoros toolokat, démonokat írogatok.
Annó C-ben kezdtem, a manuális kipróbálás, szúrópróba-szerű "nagyjából jónak tűnik" elég volt. De igazán más elterjedt lehetőségre sem láttunk akkoriban példát.

Ma például a Rust nyelvben már a nyelvi környezet lehetővé teszi az automata unit test és automata integration test beillesztését, amit a fejlesztői kézikönyvek is a fő támák között bemutatnak: https://doc.rust-lang.org/book/second-edition/ch11-00-testing.html

( 6030999 | 2018. 06. 01., p – 13:21 )

Nem tudom, milyen nyelvről van szó, de az 5-6 elgépelésből nem fogott volna meg néhányat valami linter-féle?

_______Peter
I am a stone. I do not move.