Administrace komentářů

Vizuální podoba v tom má určitě zastoupení, ale gró každého účetního programu (a masivně větší zdroj možný chyb) je v obsahu té faktury a v tom jak se k němu dospěje.

jenže vám je houby platné, když se dospěje ke správnému výsledku, když pak uživateli třeba celkovou částku prezentujete tak, že to pochopí jako variabilní symbol.

Ale tahle chyba je jednak triviální na odhalení a hlavně a zejména jde obsah a formu od sebe oddělit tak, že mají minimální vzájemné ovlivnění.

Protože uvádím triviální příklady. Ve skutečnosti je to často složitější, a nejde jen o vzhled, ale také o chování – a to nejen chování jedné „obrazovky“, ale třeba taky o workflow.

Takže to, že lidi komunikují s programem přes GUI neklade žádné omezení na testování funkčnosti toho programu. To je přece základ MVC.

Samozřejmě, že to klade omezení. Když v MVC otestujete jenom M a trochu C, neotestoval jste všechno a v tom zbytku pořád mohou být chyby.

Představte si naopak, že vlivem deadlocku kdesi hluboko mezi servicama toho programu se té faktury nedočkáte, nebo vlivem přetečení čehosi naúčtujete někomu mínus miliardu korun. Nebo že váš programátor, na kterém necháte vyjasnění nejasné specifikace, poplete má dáti a dal.

Já si to představit dokážu. To jsou ale věci, které se dají testovat automaticky (aspoň některé, u toho deadlocku to nemusí být vůbec snadné). Vy si ale představte, že se té faktury nedočkáte kvůli chybě v GUI nebo workflow. Vás to evidentně vůbec netrápí, mně je naopak celkem jedno, jestli je to chyba v logice aplikace nebo v GUI nebo v čemkoli jiném, podstatné je pro mne to, že výsledek nefunguje.

Specifikace nedělám - to lze nahradit těmi testy.

Uf. Doufám, že se s výsledkem nikdy nepotkám.

A testy dělám společně s kódem.

Tím spíš by vás mělo trknout, že když uděláte chybu v kódu, je dost pravděpodobné, že stejnou chybu uděláte i v testu.

A z mojí zkušenosti odhaduju, že brzo zjistíte, že ten bod, kde už nový test bude redundantní proti ostatním, není tak daleko.

To těžko. Zatím jste nedokázal vyjmenovat všechny testy ani pro takovou trivialitu, jako je cat. Není tak daleko bod, u kterého začnu předpokládat, že pokud se testovaný kód chová tak, jak si myslím, další testy už nepokrývají nic tak zajímavého. Pak ale potřebuju tenhle předpoklad ověřovat ručním testováním a hledat při něm další zajímavé oblasti.

Ale pak tam máte 5 vývojářů, a ti potřebujou dělat a nečekat na testera.

První, kdo ten kód bude testovat, je snad právě ten vývojář, který to napsal. A ten potřebuje psát a testovat, a ne čekat na jiného vývojáře, až opraví svou chybu, kvůli které testovat nemůže.

To si udělají ti vývojáři už sami na základě znalostí/konkrétního zadání které jim předá ten tester.

No právě. Ale kdy to mají chudáci dělat, když to mají napsat a komplet otestovat za 4 hodiny?

Naopak, to k tomu patří, a vzájemně se to podporuje.

Nikoli. To, že funkcionalita musí být napsaná a komplet otestovaná za 4 hodiny se vylučuje s tím, že budete ručně testovat a hledat místa, kde by mohly nastávat problémy.