Azt értem, hogy neked elvi problémád van, csak azt nem értem, hogy ki állított bármi olyat, hogy kizárólag így kell tesztelni, vagy hogy ettől biztosan hibátlan lesz a szoftver. Olyat sem, hogy például ettől a fizikai méretezések jók lesznek, vagy hogy azt is így kellene csinálni. Az ilyen jellegű tesztek azért vannak, hogy a te munkafolyamatodat segítsék. Nem azzal, hogy hibátlan lesz tőlük a szoftver, hanem azzal, hogy segítenek belátni, hogy azt csinálja, amit szeretnél, hogy csináljon.
Ezen a mondatodon látszik legjobban, hogy nem érted az egészet: "Akárhova is fejlődött a szakma, alacsony szinten rendszerben, időzítésekben, nyomatékban, áramban, sebességben, nyomásban, zajban kell gondolkodni, a hibátlan software nagyszerű, csak kevés." Ugyanis persze, hogy abban kell gondolkodni. Szó nincs itt arról, hogy ez megváltozott volna. Arról van szó, hogy miközben ezekben gondolkodunk, aközben hogyan haladunk a munkánkkal, hogyan nem viszünk be hibákat később, vagy más által csinált részekbe, hogyan marad más számára is átlátható a kód. Nem arról, hogy hirtelen már másban kellene gondolkodni. A változásoknál meg olyasmikre gondolj -- bár ez a ti kontextusotokban pont nem a legjobb példa, és nem is tesztelés -- de még nekem is azt tanították, hogy legyen rendesen kommentelve, itt a szálban is előjött. Ezzel szemben ma már egy "szoftveres" reviewn húzni fogja rá az orrát, és el fogja mondani, hogy ha ide ezt le kellett írni, akkor nem jól olvasható az a kód, szervezzük egy kicsit át, nevezzünk el még egy függvényt, valamit csináljunk, hogy magyarázkodás helyett a kód legyen olvasható.
Ez az egész teljesen ortogonális arra nézve, hogy itt időzítésekben meg miben kell gondolkodni.
(Az meg nekem is tényleg kérdésem, hogy hogy lehet a hibátlan szoftver kevés. A hibátlan szoftver pont azt csinálja, amit kell neki)