Administrace komentářů

A to se chcete místo toho náhodně strefovat do testu o kterém nevíte co testuje?

Ne. Já chci napsat aplikaci, která dělá to, co se od ní čeká.

Akceptační test ověřuje zdokumentované chování z hlediska uživatele, 100% pokrytí mi nepřijde jako "nic" nebo "1 promile".

Jenže to zdokumentované chování představuje 1 promile toho, co uživatel používá a očekává. Takže tím 100% pokrytím dokumentovaného chování dostanete to promilové pokrytí využívaného a očekávaného chování.

Za prvé uživatel je svéprávný člověk a upgradovat si může až bude chtít

Takže programátor/uživatel si nemusí každý půl den přebírat práci jiných vývojářů, ale může si ji převzít, až bude chtít – to tady propaguju celou dobu.

To ňák nechápu - text se změní nebo přidá - a co (a jak) na tom chcete testovat? Jakému durchfallu tím testem chcete předejít?

Pořád jste psal o tom, jak automatizované testy zajistí správné fungování aplikace. Změněný nebo přidaný text je příklad, který automatizované testy nedokážou postihnout.

Nevím kde jsem napsal že mám něco dávno napsané.

Pořád jste se tvářil, že to, že projdou automatizované testy, pro vás znamená, že aplikace je funkční. Jak dokážete poznat, že jsou funkční knihovny, na kterých ta aplikace závisí, když na ně nemáte testy?

Pokud bych tomu přestal věřit, tak se propadnu technologicky i myšlenkově o 20 let dozadu. Máte nějakou lepší metodiku?

Ano, mám. Nevěřit slepě tomu, že automatizovanými testy lze otestovat významnou část aplikace (zvlášť pokud je to aplikace založená na silné interakci s uživatelem). Připustit si, že značná část funkcionality aplikace se nedá ověřit jinak, než používáním té aplikace. A to nějakou dobu trvá. Proto v době vývoje nechám programátory, aby používali svou novou část, ale ostatní části aby měli pokud možno nezměněné. Teprve pokud se prokáže, že alespoň základní funkcionalita je použitelná, šíří se k dalším vývojářům. Tím se předchází tomu, aby jedna rozbitá funkcionalita bránila ve vývoji a testování ostatním.