Administrace komentářů

Psané specifikace, zákony, obecně známé věci, dohody…

A jak ošetříte situace, kdy si programátor vyloží špatně neco v psané specifikaci nebo zákoně, v obecně známé věci se plete, nebo se k němu dohoda dostane zkresleně?

Neexistující vstupní soubor, chyba při čtení nebo zápisu, změny ve vstupním souboru v průběhu čtení… To všechno jsou věci, které nejsou v dokumentaci popsané, a při tom spoléháte na to, že se nějak budou chovat. Nemusíte zrovna čekat, že při neexistujícím souboru to skončí s chybovým kódem 354, ale nejspíš očekáváte, že se to bude chovat nějak „rozumně“ a třeba to v takovém případě nesmaže všechny soubory, které smazat může. Přestože by takové chování nebylo v rozporu s manuálem.

A to "rozumně" si právě může každý vykládat po svém. (Pojďme se dohadovat, jestli když neexistuje 5 souborů z 100, tak to má okamžitě zařvat a umřít, nebo je tiše přeskočit.) Co je horší, to nezdokumentované chování může být nekonzistentní v různých modulech aplikace, nebo se i náhodně měnit po dobu života té aplikace, podle toho kdo to zrovna programoval.

Proto je dobré zdokumentovat i chování při chybách a následně ho můžete jednoduše podpořit nějakým testem. Není to ale 999 případů, je to jeden případ a leckdy i jedna věta v manuálu.

Můžete třeba jít po té nejjednodušší variantě, a napsat, že když je chyba, tak konec. Jako test použijete např. neexistující soubor. Tím akceptační testování končí. To, že se chyby nikde nezatloukají a všechny interní funkce je buď zpracují nebo propagují dál, je už věc unit testů, které uživatel nemusí řešit.

No sláva. Takže už jsme snad dospěli k tomu, že spoustu věcí rozumně automaticky testovat nejde nebo se to nevyplatí.

Špatně jste si to vyložil. Mně se nevyplatí psát testy za někoho jiného (tj. dodavatele knihovny), ne že se nevyplatí mít testy vůbec.

Takže automatizované testy pokrývají pouze část funkcionality (zpravidla menší).

Menší co? Počet řádků v kódu? Záleží co na nich je. Nebo méně důležité funkce? Proč bych dělal testy na ně a ne na ty důležitější?

Takže to, že nějaký kód prošel automatizovanými testy, ještě vůbec neznamená, že je výsledek funkční.

To ne. Ale pokud kód testy neprošel, tak výsledek funkční není. (Buď je chyba ve funkci nebo její specifikaci - testech.)

U aplikace, která je postavená především na interakci s uživatelem, je to značná část. Protože živého člověka se nám zatím moc nedaří simulovat.

Pořád si neumím představit, o čem mluvíte, tak mi dejte nějaký příklad. Pokud možno prosím z praxe.

Koncept, který nutí celý vývojářský tým zabývat se chybou jednoho programátora a odložit kvůli ní svou práci, evidentně zdržuje spoustu lidí od jejich práce. Koncept, který neumožňuje programátorovi soustředit se na jednu změnu, ale neustále ho vyrušuje spoustou dalších změn, také zpomaluje práci a zvyšuje pravděpodobnost chyb. Nevidím tam však nic, co by tyhle dvě zásadní nevýhody mohlo převážit.

Vnímáte to špatně, proto jsem doporučoval si to dohledat a nastudovat.