načítání...
nákupní košík
Košík

je prázdný
a
b

E-kniha: Testování softwaru řízené návrhem - Matt Stephens; Doug Rosenberg

Testování softwaru řízené návrhem
-6%
sleva

Elektronická kniha: Testování softwaru řízené návrhem
Autor: ;

Pokud jako vývojář neberete problematiku testování na lehkou váhu, jistě nechcete touto činností strávit zbytečně dlouhou dobu. Seznamte se s testováním softwaru řízeným ...
Produkt teď bohužel není dostupný.

»hlídat dostupnost


hodnoceni - 75.7%hodnoceni - 75.7%hodnoceni - 75.7%hodnoceni - 75.7%hodnoceni - 75.7% 100%   celkové hodnocení
1 hodnocení + 0 recenzí

Specifikace
Nakladatelství: Computer press
Dostupné formáty
ke stažení:
PDF
Upozornění: většina e-knih je zabezpečena proti tisku
Médium: e-book
Počet stran: 336
Rozměr: 23 cm
Úprava: ilustrace , portréty
Vydání: Vyd. 1.
Název originálu: Design driven testing
Spolupracovali: překlad Lukáš Krejčí
Jazyk: česky
ADOBE DRM: bez
ISBN: 978-80-251-3607-2
Ukázka: » zobrazit ukázku
Popis

Pokud jako vývojář neberete problematiku testování na lehkou váhu, jistě nechcete touto činností strávit zbytečně dlouhou dobu. Seznamte se s testováním softwaru řízeným návrhem a zrychlete tak proces testování, který bude efektivní, ale nevynechá nic důležitého.

Dvojice autorů vás v dvanácti kapitolách provede metodikou testování řízeného návrhem (Design-Driven Testing – DDT). Ta využívá návrh pro přesné vymezení míst, kde je nutné založit kritické testy. Seznámíte se s osvědčeným procesem vývoje softwaru, který se zaměřuje na tvorbu a údržbu testů jednotek a testů přijatelnosti založených a řízených návrhem. V úvodních kapitolách se dozvíte také o rozdílech mezi touto metodikou a známějším programováním řízeným testy (Test-Driven Development – TDD).

Publikace vás mimo jiné naučí, jak:
- Navrhnout a testovat jednotky
- Pracovat s konceptuálním návrhem
- Testovat přijatelnost pro jednotlivé části projektu
- Přizpůsobit návrh snadnějším a rychlejším testům
- Automatizovat integrační testy
- Ověřovat použité algoritmy

Testování softwaru řízené návrhem se vrací zpět k myšlence, že testování slouží k ověření návrhu místo toho, aby testy jednotek návrh nahrazovaly.

O autorech:
Matt Stephens je softwarový konzultant a zakladatel nezávislého knižního vydavatelství Fingerpress (www.fingerpress.co.uk). Psal pro mnoho časopisů a webů, například pro The Register a Application Development Trends. Na Internetu jej najdete na webu společnosti Software Reality (http://articles.softwarereality.com).

Doug Rosenberg založil v roce 1984 společnost ICONIX (www.iconixsw.com). Po několika letech práce na tvorbě CASE nástrojů začal školit společnosti v objektově orientované analýze a návrhu. Specializuje se na školení v oblasti jazyků UML a SysML. Od roku 1995 se stal spoluautorem řady odborných titulů.

Předmětná hesla
Související tituly dle názvu:
Testování softwaru řízené návrhem Testování softwaru řízené návrhem
Rosenberg Doug, Stephens Matt
Cena: 507 Kč
Efektivní testování softwaru Efektivní testování softwaru
Bureš Miroslav, Renda Miroslav, Doležel Michal, kolektiv
Cena: 355 Kč
Efektivní testování softwaru Efektivní testování softwaru
kolektiv a, Renda Miroslav, Bureš Miroslav, Doležel Michal
Cena: 302 Kč
Recenze a komentáře k titulu
Zatím žádné recenze.


Ukázka / obsah
Přepis ukázky
Matt Stephens, Doug Rosenberg Testování softwaru řízené návrhem Computer Press, a. s. Brno 2011 Testování softwaru řízené návrhem Matt Stephens, Doug Rosenberg Computer Press, a. s. , 2011. Vydání první. Original edition copyright © 2010 by Matt Stephens and Doug Rosenberg. All rights reserved. Czech edition copyright 2011 by Computer Press. All rights reserved. Autorizovaný překlad z originálního anglického vydání Design Driven Testing. Originální copyright: © 2010 by Matt Stephens and Doug Rosenberg. All rights reserved. Překlad: © Computer Press, a.s., 2011. Computer Press, a. s., Holandská 3, 639 00 Brno Objednávky knih: http://knihy.cpress.cz distribuce@cpress.cz tel.: 800 555 513 ISBN 978-80-251-3607-2 Prodejní kód: K1950 Vydalo nakladatelství Computer Pr ess, a. s., jako svou 4028. publikaci. © Computer Press, a. s. Všechna práva vyhrazena. Žádná část této publikace nesmí být kopírována a rozmnožována za účelem rozšiřování v jakékoli formě či jakýmkoli způsobem bez písemného souhlasu vydavatele. Překlad: Lukáš Krejčí Jazyková korektura: Alena Láníčková Sazba: Dagmar Hajdajová Rejstřík: Daniel Štreit Obálka: Martin Sodomka Komentář na zadní straně obálky: Martin Herodek Technická spolupráce: Jiří Matoušek, Zuzana Šindlerová, Dagmar Hajdajová Odpovědný redaktor: Martin Herodek Technický redaktor: Jiří Matoušek Produkce: Petr Baláš Obsah Úvod ........................................................................................ 11 O autorech ............................................................................... 13 O odborných korektorech ...................................................... 14 Poděkování ............................................................................. 15 Předmluva ............................................................................... 16 Část I DDT vs. TDD Kapitola 1 Někdo to má pozpátku .......................................................... 19 Problémy, které řeší testování řízené návrhem ...................................................... 20 Vědět, kdy je hotovo, je obtížné............................................................................................... ..... 20 Ponechání testování na později je dražší .................................................................................. 21 Testování špatně navrženého kódu je těžké ............................................................................ 21 Je snadné opomenout testy na úrovni zákazníka .................................................................. 22 Vývojáři bývají samolibí ................................................................................................................... 22 Testy někdy postrádají smysl.......................................................................................................... 22 Rychlý přehled metodiky DDT bez ohledu na nástroje ....................................... 22 Struktura testování řízeného návrhem ....................................................................................... 23 Metodika DDT v akci.......................................................................................................................... 25 Jak se metodiky TDD a DDT odlišují ........................................................................... 26 Ukázkový projekt: představení webové aplikace Mapplet 2.0 ......................... 28 Shrnutí ................................................................................................................................... 29 Kapitola 2 Úvodní příklad s metodikou TDD .......................................... 33 10 nejdůležitějších vlastností metodiky TDD .......................................................... 34 10. Testy řídí návrh ............................................................................................................................. 34 Obsah 4 9. Celkový nedostatek dokumentace .......................................................................................... 34 8. Vše je test jednotky ....................................................................................................... ................ 35 7. Testy metodiky TDD nejsou tak docela testy jednotek (nebo snad ano?) ................ 35 6. Testy přijatelnosti poskytují zpětnou vazbu vůči požadavkům .................................... 35 5. Metodika TDD propůjčuje důvěru k provádění změn ...................................................... 35 4. Návrh se vyvíjí inkrementálním způsobem .......................................................................... 36 3. Nějaký předběžný návrh je v pořádku ................................................................................... 36 2. Metodika TDD produkuje velké množství testů ................................................................. 36 1. Metodika TDD je nehorázně obtížná ...................................................................................... 37 Přihlašování implementované pomocí metodiky TDD ........................................ 37 Seznámení s požadavkem ............................................................................................................... 37 Přemýšlejte o návrhu ........................................................................................................................ 40 Nejdříve se napíše první test psaný jako první test ............................................................... 41 Vytvoření kódu pro kontrolu přihlášení, aby test prošel ..................................................... 44 Vytvoření mockobjektu .................................................................................................................... 46 Refaktorizace kódu ukazující rozvoj návrhu ............................................................................. 48 Testy přijatelnosti s metodikou TDD ........................................................................... 54 Závěr: metodika TDD je opravdu nehorázně obtížná .......................................... 54 Shrnutí ................................................................................................................................... 56 Kapitola 3 Úvodní příklad s metodikou DDT .......................................... 57 10 nejdůležitějších vlastností metodiky ICONIX/DDT .......................................... 58 10. Metodika DDT zahrnuje testy obchodních požadavků ................................................... 58 9. Metodika DDT zahrnuje testy scénářů ................................................................................... 58 8. Testy jsou odvozené z návrhu ................................................................................................... 58 7. Metodika DDT zahrnuje testy řadičů ..................................................................................... 59 6. Metodika DDT testuje chytřeji, ne obtížněji ....................................................................... 59 5. Testy jednotek metodiky DDT jsou „klasickými“ testy jednotek ................................... 59 4. Testovací případy metodiky DDT lze transformovat do testovacího kódu .............. 59 3. Testovací případy metodiky DDT vedou k testovacím plánům .................................... 60 2. Testy metodiky DDT jsou užitečné pro vývojáře i členy QA týmů ............................... 60 1. Metodika DDT dokáže eliminovat nadbytečné úsilí ......................................................... 60 Přihlašování implementované pomocí metodiky DDT........................................ 60 Krok 1: Vytvoření diagramu robustnosti ................................................................................... 62 Krok 2: Vytvoření testovacích případů ........................................................................................ 66 Krok 3: Přidání scénářů ..................................................................................................................... 68 Krok 4: Transformace testovacích případů testů řadiče do tříd ......................................... 70 Krok 5: Generování testovacího kódu řadičů ........................................................................... 72 Krok 6: Nakreslení diagramu posloupností ............................................................................... 75 Obsah 5 Krok 7: Vytvoření testovacích případů pro testy jednotek .................................................. 78 Krok 8: Doplnění testovacího kódu ............................................................................................. 82 Shrnutí ................................................................................................................................... 86 Část II Metodika DDT v praxi: Mapplet 2.0, web pro cestovatele Kapitola 4 Seznámení s Mapplet ............................................................. 91 10 nejdůležitějších osvědčených postupů metodiky ICONIX Process/DDT ....................................................................................................... 92 10. Vytvořte architekturu .................................................................................................................. 93 9. Dohodněte se na obchodních požadavcích a testujte vůči nim ................................. 94 8. Návrh odvoďte z problémové domény ................................................................................. 96 7. Podle storyboardů uživatelského rozhraní napište případy užití ................................ 98 6. Pro ověření, že případy užití pracují, napište testy scénářů ........................................ 100 5. Testujte vůči konceptuálnímu a podrobnému návrhu ................................................. 104 4. Model pravidelně aktualizujte ............................................................................................... 104 3. Testy přijatelnosti udržujte synchronizované s požadavky ......................................... 111 2. Mějte automatizované testy stále aktuální ....................................................................... 112 1. Kandidáta na finální verzi porovnejte s původními případy užití............................. 112 Shrnutí ................................................................................................................................ 116 Kapitola 5 Podrobný návrh a testování jednotek ................................ 117 10 nejdůležitějších „úkolů“ při testování jednotek ............................................. 118 10. Začněte diagramem posloupností ....................................................................................... 119 9. Na základě návrhu identifikujte testovací případy ......................................................... 120 8. Pro každý testovací případ napište scénáře ...................................................................... 122 7. Testujte chytřeji: nepište překrývající se testy .................................................................. 124 6. Testovací případy transformujte do jazyka UML ............................................................. 126 5. Napište testy jednotek a doprovodný kód ........................................................................ 130 4. Napište testy jednotek jako testy „bílé skříňky“ ............................................................... 133 3. Použijte framework pro mock objekty ................................................................................ 137 2. Algoritmickou logiku testujte pomocí testů jednotek .................................................. 140 1. Napište samostatnou sadu integračních testů ................................................................ 141 Shrnutí ................................................................................................................................ 142 Obsah 6 Kapitola 6 Konceptuální návrh a testování řadičů .............................. 143 10 nejdůležitějších „úkolů“ při testování řadičů .................................................. 145 10. Začněte diagramem robustnosti .......................................................................................... 145 9. Z řadičů odvoďte testovací případy ..................................................................................... 148 8. Pro každý testovací případ definujte jeden či více scénářů ........................................ 151 7. Vyplňte pole Description, Input a Acceptance Criteria ................................................. 154 6. Vygenerujte testovací třídy ................................................................................................ ..... 155 5. Implementujte testy .................................................................................................................. 159 4. Napište kód, který se snadno testuje .................................................................................. 160 3. Napište testy řadičů jako testy „šedé skříňky“ .................................................................. 162 2. Zřetězte testy řadičů dohromady ......................................................................................... 163 1. Napište samostatnou sadu integračních testů ................................................................ 165 Shrnutí ................................................................................................................................ 166 Kapitola 7 Testování přijatelnosti: rozvinutí scénářů v případu užití ....................................................................... 167 10 nejdůležitějších „úkolů“ při testování scénářů ............................................... 169 Případy užití aplikace Mapplet .................................................................................. 169 10. Začněte popisným případem užití ....................................................................................... 170 9. Proveďte transformaci na strukturovaný scénář ............................................................. 173 8. Ujistěte se, že všechny cesty mají kroky ............................................................................. 174 7. Přidejte předběžné a následné podmínky ........................................................................ 175 6. Vygenerujte diagram činností ................................................................................................ 175 5. Rozviňte „vlákna“ pomocí externích testů ......................................................................... 176 4. Umístěte testovací případ do diagramu testovacích případů ................................... 178 3. Ponořte se do zobrazení testování nástroje Enterprise Architect ............................ 179 2. Do testovacích scénářů přidávejte podrobnosti ............................................................. 179 1. Vygenerujte dokument s plánem testů .............................................................................. 180 Morální ponaučení ........................................................................................................ 181 Shrnutí ................................................................................................................................ 184 Kapitola 8 Testování přijatelnosti: obchodní požadavky ................... 185 10 nejdůležitějších „úkolů“ při testování požadavků ......................................... 186 10. Začněte doménovým modelem ............................................................................................ 187 9. Napište testy obchodních požadavků ................................................................................ 189 8. Požadavky vymodelujte a uspořádejte ............................................................................... 189 7. Vytvořte testovací případy z požadavků ............................................................................ 192 Obsah 7 6. Projděte svůj plán se zákazníkem ......................................................................................... 19 4 5. Napište ruční popisy testů ....................................................................................................... 198 4. Napište automatizované testy požadavků ........................................................................ 198 3. Exportujte testovací případy .................................................................................................. 199 2. Testovací případy náležitě zpřístupněte ............................................................................. 199 1. Zapojte svůj tým! ....................................................................................................................... 200 Shrnutí ................................................................................................................................ 200 Část III Pokročilá metodika DDT Kapitola 9 Antivzory při testování jednotek ........................................ 205 Chrám zkázy (neboli kód) ............................................................................................ 206 Celkový pohled ................................................................................................................................. 207 Třída HotelPriceCalculator ............................................................................................................ 208 Podpůrné třídy.................................................................................................................................. 209 Servisní třídy ...................................................................................................................................... 210 Antivzory ............................................................................................................................ 212 10. Komplexní konstruktor ............................................................................................................. 212 9. Stratosférická hierarchie tříd .................................................................................................. 213 8. Statický spouštěč ........................................................................................................................ 215 7. Statické metody a proměnné ................................................................................................217 6. Návrhový vzor Singleton .......................................................................................................... 218 5. Těsně svázaná závislost ............................................................................................................. 221 4. Obchodní logika v kódu uživatelského rozhraní............................................................. 223 2. Servisní objekty deklarované jako finální .......................................................................... 225 1. Nedomyšlené funkce dobromyslného programátora ................................................... 225 Shrnutí ................................................................................................................................ 225 Kapitola 10 Návrh s ohledem na snazší testování ................................. 227 Seznam deseti nejdůležitějších úkolů pro „návrh s ohledem na testování“ ............................................................................................ 228 Chrám zkázy – důkladně pročištěný........................................................................ 229 Případ užití – pochopení toho, co vlastně chceme dělat ................................................. 230 Identifikování testů řadičů ........................................................................................................... 231 Test výpočtu celkové ceny ........................................................................................................... 232 Test načtení poslední ceny ........................................................................................................... 233 Obsah 8 Návrh s ohledem na snazší testování ...................................................................... 234 10. Inicializační kód udržujte mimo konstruktor .................................................................... 235 9. S dědičností šetřete ....................................................................................................... ............ 236 8. Vyvarujte se statických inicializačních bloků .................................................................... 237 7. Používejte metody a proměnné na úrovni objektu ....................................................... 238 6. Nepoužívejte návrhový vzor Singleton .............................................................................. 238 5. Udržujte své třídy oddělené ................................................................................................... 239 4. Nedávejte obchodní logiku do kódu uživatelského rozhraní .................................... 241 3. Použijte testování černé skříňky a šedé skříňky .............................................................. 246 2. Modifikátor „final“ používejte pro konstanty a obecně jím neoznačujte komplexní typy, jako jsou servisní objekty .................. 246 1. Držte se případů užití a návrhu ............................................................................................. 247 Podrobný návrh pro případ užití Quote Hotel Price .......................................... 247 Test řadiče pro výpočet celkové ceny ...................................................................................... 249 Test řadiče pro načtení poslední ceny .................................................................................... 249 Předělaný návrh a kód .................................................................................................................. 250 Shrnutí ................................................................................................................................ 251 Kapitola 11 Automatizované integrační testování ................................ 253 Seznam 10 nejdůležitějších „úkolů“ pro integrační testování ........................ 254 10. Testovací vzory hledejte ve svém konceptuálním návrhu ........................................... 255 9. Nezapomeňte na testy zabezpečení ................................................................................... 256 8. Rozhodněte, která „úroveň“ integračních testů se má psát ........................................ 258 7. Integrační testy na úrovni řadičů či jednotek odvoďte z konceptuálního návrhu ........................................................................................................ 259 6. Testy scénářů odvoďte ze scénářů případů užití ............................................................. 262 5. Napište celkové testy scénářů ................................................................................................ 263 4. Použijte testovací framework „přátelský k obchodnímu hledisku“ .......................... 267 3. Kód grafického uživatelského rozhraní testujte v rámci testů scénářů .................. 270 2. Nepodceňujte obtížnost integračního testování ............................................................ 270 1. Nepodceňujte hodnotu integračních testů ...................................................................... 274 Hlavní body při psaní integračních testů ............................................................... 274 Shrnutí ................................................................................................................................ 276 Obsah 9 Kapitola 12 Testování algoritmů ............................................................. 277 10 nejdůležitějších „úkolů“ při testování algoritmů ........................................... 278 10. Začněte řadičem z konceptuálního návrhu ...................................................................... 279 9. Rozviňte řadiče do návrhu algoritmu ................................................................................ 281 8. Diagram volně propojte s doménovým modelem ......................................................... 282 7. Rozdělte rozhodovací uzly obsahující více než jednu kontrolu ................................ 284 6. Pro každý uzel vytvořte testovací případ ........................................................................... 284 5. Pro každý testovací případ definujte testovací scénáře ............................................... 285 4. Vytvořte vstupní data z nejrůznějších zdrojů ................................................................... 288 3. Přiřaďte logický tok do jednotlivých metod a tříd .......................................................... 289 2. Napište testy jednotek jako testy „bílé skříňky“ ............................................................... 293 1. Aplikujte metodiku DDT na další návrhové diagramy .................................................. 303 Shrnutí ....................................................................................................................... ......... 304 Příloha Alenka v říši případů užití .................................................... 305 Úvod .................................................................................................................................... 306 Část 1 .................................................................................................................................. 306 Alenka při čtení usnula .................................................................................................................. 307 Příslib vývoje řízeného případy užití ........................................................................................ 307 Model analýzy spojuje text případů užití s objekty ............................................................ 308 Jednoduché a přímočaré .............................................................................................................. 308 Stereotypy <<includes>> a <<extends>> ........................................................................... 308 Máme zpoždění! Musíme začít programovat! ...................................................................... 309 Alenka se podivuje, jak se dostat od případů užití ke kódu ............................................ 309 Abstraktní... podstata ................................................................................................................... 309 Až příliš abstraktní? ......................................................................................................................... 310 Teleocentricita... ............................................................................................................................. 310 Skutečně je nutné to vše specifikovat pro každý případ užití? ...................................... 311 Část 2 .................................................................................................................................. 312 Alenka dostala žízeň ....................................................................................................................... 312 Alenka pociťuje mdloby ................................................................................................................ 313 Imagine... (s omluvou Johnu Lennonovi) ............................................................................ 313 Párové programování znamená, že se nikdy nezaznamenají požadavky .................. 314 Na zaznamenání požadavků není čas ...................................................................................... 315 Stejně tak můžete říci, že „kód je návrh“ ................................................................................. 315 Koho zajímají případy užití? ........................................................................................................ 316 Projekt C3 ukončen ......................................................................................................................... 317 Obsah 10 Jen a pouze jedinkrát? ........................................................................................................ ........... 318 Alenka odmítá začít programovat bez zapsaných požadavků ....................................... 318 Spáchala jsi VPN... .......................................................................................................................... 320 Model CMM je mrtvý! Pryč s její hlavou! ................................................................................ 321 Seriózní refaktorování návrhu ..................................................................................................... 321 Část 3 .................................................................................................................................. 321 Alenka se probouzí ......................................................................................................................... 322 Uzavření díry mezi „Co“ a „Jak“ ................................................................................................... 323 Statické a dynamické modely jsou spojené dohromady .................................................. 323 Přidělování chování se odehrává na diagramu posloupností ........................................ 323 Ponaučení, které z toho plyne .................................................................................................... 324 Závěr Byl smažno a lepě svyhlé testy... ......................................... 325 Rejstřík .................................................................................. 331 Úvod Jim je jako programový manažer pro mapovací softwarový produkt ArcGIS společnosti ESRI odpovědný za  každodenní sestavování 20 milionů řádků kódu. Dříve spravovat dopravní a  logistické oddělení pro ESRI Professional Serv ices, kde se mu podařilo dokončit bez překročení termínu a rozpočtu řadu softwarových projektů v  hodnotě milionů dolarů, přičemž používal techniky návrhu popsané v této knize. Spousta lidí má řadu vyhraněných názorů na prakticky všechny stránky testování softwaru. Viděl jsem nebo slyšel o různých metodikách, systémech, procedurách, procesech, vzorech, nadějích, modlitbách i prostém štěstí, že se některé cesty kódu nikdy neprovedly. S veškerou touto pomocí musíme přece vymyslet, jak dodávat výjimečný, neprůstřelný a bezchybný software, ne? Přesto s každým novým vydáním další skvělé, nejstabilnější revize našeho softwarového produktu dělají testovací inženýři stále takový ten bolestivý obličej (znáte to) a při otázce „Máš příslušné testy napříč všemi vrstvami softwaru?“ se stahují zpět. Příčinou bolestivého obličeje je fakt, že pravdivou odpovědí na tuto otázku je téměř vždy: „Myslím, že ano, ale ve skutečnosti neznám všechny oblasti, pro které bych měl mít testy.“ A software se i tak vydá, prevít jeden. To je pak pracovní jistota pro tým technické podpory, protože chyby ve vydaném produktu se vrátí přímo k vašemu týmu pro další servisní balíček nebo nouzovou rychlou opravu. Jde to ale dělat mnohem lépe a tato kniha vám ukáže, jak. Tato kniha vás provede osvědčeným procesem vývoje softwaru s názvem ICONIX Process a zaměří se na tvorbu a údržbu testů jednotek a testů přijatelnosti založených a řízených návrhem softwaru. Jedná se o testování řízené návrhem (Design-Driven Testing – DDT). Svůj návrh tak využijete pro přesné vymezení míst, kde je nutné založit kritické testy na návrhu a chování objektů. Nejedná se o návrh řízený testy (Test-Driven Design – TDD), kdy se nejdříve píší testy jednotek, a to ještě před dokončením návrhu a zahájením programování. Nevím, jak je to u vás, ale předvídání budoucnosti je myslím docela obtížné, a  přimět softwarové inženýry, aby naprogramovali něco, co „pasuje“ do určité sady testů, je dokonce ještě těžší. Zatímco spousta lidí má na testování různé názory, je tu jedna věc, na které se všichni asi shodneme: testování je často velice obtížné a složité. Jako programový manažer velkého vývojového týmu vím, jak rychle se může testování vymknout z rukou nebo prostě pozastavit celý projekt. Organizace vydávají na testování velmi rozdílné prostředky a naneštěstí existují i velké rozdíly, co se týče návratnosti takto investovaných prostředků. Je možné provádět příliš mnoho testování a investované prostředky tak promarnit. Avšak pravděpodobnější je, že se provede příliš málo testování (samozřejmě s představou, že se udělalo více než dost), v nesprávných oblastech softwaru a s nedostatečnými investicemi. K tomu může dojít proto, že prostě nevíte, kam testy umístit pro vyvážené investice a získat tak správné testovací pokrytí. Tato kniha vám na příkladu návrhu a vybudování skutečné mapové webové aplikace ukáže, jak docílit této vyváženosti a optimalizovat návratnost investic do testování. Při použití metodik ICONIX Pro- Úvod 12 cess a DDT je naprosto jasné, jaké testy jsou nutn é a kde mají být. Ba co víc, řadu z těchto testů za vás automaticky vygenerují používané nástroje (v tomto případě nástroj Enterprise Architect od společnosti Sprax Systems), které (kromě toho, že jde o naprosto skvělé nástroje) jsou pro váš projekt nesmírně cenné. Pokud tedy potřebujete vytvořit skvělý software s použitím agilního procesu, kdy se vám testy vygenerují téměř zadarmo, pak je tato kniha právě pro vás. Jim McKinney Programový manažer produktu ArcGIS, společnost ESRI O autorech Matt Stephens je softwarový konzultant s finančními organizacemi v Centrálním Londýně a zakladatel nezávislého knižního vydavatelství Fingerpress (www.fingerpress.co.uk). Psal pro mnoho časopisů a webů, například pro The Register a Application Development Trends. Na Internetu jej najdete na webu společnosti Software Reality (http://articles.softwarereality.com). Doug Rosenberg v roce 1984 ve svém obývacím pokoji založil společnost ICONIX (www.iconixsw. com). Po několika letech práce na tvorbě CASE nástrojů začal školit společnosti v objektově orientované analýze a návrhu, která se specializuje na školení v oblasti jazyků UML a SysML a nabízí jak místní kurzy, tak i  kurzy s  otevřeným zápisem. V  roce 1993 vyvinul jednotný Booch/Rumbaugh/ Jacobson přístup k modelování, což bylo o několik let dříve, než se objevil jazyk UML, a kolem roku 1995 začal psát knihy. Testování řízené návrhem je šestou knihou z oblasti softwarového inženýrství (a čtvrtou s Mattem Stephensem). Kromě toho vytvořil bezpočet multimediálních tutoriálů, jako je například Enterprise Architect for Power Users, a několik elektronických knih, mezi něž patří kupříkladu Embedded Systems Development with SysML. Když nepíše a neučí, tak rád vytváří panoramatické fotografie virtuální reality, které si můžete prohlédnout na jeho webu pro cestovatele VResorts.com. O odborných korektorech Jeffrey P. Kantor je manažer projektu správy dat teleskopu LSST (Large Synoptic Survey Telescope – velký synoptický přehledový teleskop). V této funkci je odpovědný za implementování výpočetních a komunikačních systémů zajišťujících kalibraci, hodnocení kvality, zpracování, archivaci a přístup koncových uživatelů a externích systémů k astronomickým obrazům a inženýrským datům produkovaným teleskopem LSST. Po čtyřech letech v Americké armádě, kde působil jako specialista zpravodajské služby na ruský jazyk a signály, začal v roce 1980 jako programátor na základní úrovni, načež zastával pozice na všech úrovních IT organizací v řadě průmyslových odvětví, včetně obrany a letectví, výroby polovodičů, geofyziky, poradenství v oblasti softwarového inženýrství, řízení domácností a budov, zboží dlouhodobé spotřeby, prodeje a elektronické komerce. Vytvářel, upravoval na míru, aplikoval a auditoval softwarové procesy pro široké spektrum organizací v průmyslu, vládě a školství. U některých z těchto organizací byl odpovědný za dosažení certifikace ISO9000 a úrovně CMM Level 2 institutu SEI. Dále poskytoval poradenství a školení více než 30 společnostem v oblasti objektově orientované analýzy a návrhu, modelování pomocí jazyka UML, testování řízené případy užití a řízení softwarových projektů. Rád tráví čas se svou rodinou, u fotbalu (jako hráč, sudí a trenér) a jezděním na kole po horách. David Putnam pracoval posledních 25 let ve vývoji softwaru a od začátku tohoto století je jedním z nejhorlivějších zastánců agilního přístupu v Anglii. Od začátku bylo jeho zaměření velmi různorodé: vytvářel databázové systémy pro stavební průmysl, pracoval ve fitness odvětví a také přednášel na univerzitě. Během té doby publikoval řadu článků o vývoji softwaru a je známou tváří na konferencích o agilním vývoji softwaru. Nyní pracuje jako nezávislý poradce v oblasti agilního vývoje softwaru a poskytuje neocenitelné rady několika z nejznámějších společností v Anglii. Poděkování Autoři by rádi poděkovali: Týmu společnosti ESRI odpovědnému za projekt Mapplet (Wolfgang Hall, Prakash Darbhamulla, Jim McKinney a Witt Mathot) za jeho práci na ukázkovém projektu v této knize. Lidem ze společnosti Sparx Systems (Geoff Sparks, Ben Constable, Tom O‘Reilly, Aaron Bell, Vimal Kumar a Estelle Gleeson) za vývoj doplňku Agi le/ICONIX a editoru strukturovaných scénářů. Alanahu Stephensovi, který byl naprosto nejlepší „Alenkou“, jaká kdy byla, a Michelle Stephensové, za její trpělivost během dalšího knižního projektu. Jeffu Kantorovi a  Robynu Allsmanovi z  projektu LSST za  jejich pomoci se specifikací expandéru vláken případu užití. Miku Farnsworthovi a lidem ze společnosti Virginia DMV, kteří se podíleli na předběžném modelování aplikace Mapplet. Barbaře Rosi-Schwartzové za její zpětnou vazbu ohledně metodiky DDT a Jerry Hambymu za sdílení jeho odborných znalosti technologie Flex a zvláště za jeho pomoc se zpětnou analýzou kódu jazyka MXML. A v neposlední řadě našim redaktorům v nakladatelství Apress: Jonathanu Gennickovi, Anitě Castrové a Mary Ann Fugatové. Předmluva Střež se nadšeného povyku kolem agilnosti Bylo smažno, když se YAGNIdní kód desetkrát za den sám sestavil. Indexové kartičky ve své křehkosti, odklizené, refaktorované návrhy. Ó synu, střež se nadšeného povyku kolem agilnosti, více kódu s pachem, více chyb na odchycení. Refaktorování bylo mnohem zábavnější, než byly schopnosti tvé na znak poražené. Své chopil testy jednotek, proti litým chybám bojoval. Zmatený přístupem TDD, zdravý rozum vyhledal. Ale v jeho dřevěném okně časovém, určeném hrou kde vládl plán, ony testy zezelenaly a vše bylo májové, dokud konečný termín nenastal. Je půl třetí, máme hotovo, je čas na svačinku chutnou. Že testy zčervenaly, pěl jsi, mátoho, vše rychlým hackem utnou! A hle, šokující myšlenka jak sen, ne testy, ale nejdříve návrh! V této báječný den, jednodušší proces byl zaveden. Bylo smažno, když se YAGNIdní kód desetkrát za den sám sestavil. Indexové kartičky ve své křehkosti, odklizené, refaktorované návrhy... ČÁST I DDT vs. TDD „Ať se vývojáři zabývají konceptuálním návrhem,“ řekl Král, toho dne již asi podvacáté. „Ne, ne!“ oponovala Královna. „Nejdříve testy – potom návrh.“ „Hloupost!“ zvolala Alenka. „Ten nápad začínat s psaním testů!“ 18 Část I: DDT vs. TDD 18 „Mlč!“ řekla Královna, která už začala měnit barvu. „Mimochodem, kolik kódu jsi v  poslední době napsala?“ jízlivě se ušklíbla. „Nebudu mlčet,“ ohradila se odvážně malá Alenka. „Testy by neměly řídit návrh, ale návrh by měl řídit testování. Testy by totiž měly ověřit, že kód pracuje tak, jak je navržený, a také že splňuje požadavky zákazníka,“ dodala, překvapená svým vhledem do pod staty věci. „Když navíc své testy odvodíte od konceptuálního návrhu, nebude testování obtížnější, ale chytřejší.“ Tato kniha je o testování, a to nejen o vizuální kontrole ve stylu QA, ale také o automatizovaném testování – řízení testů jednotek, testů řadičů a testů scénářů podle vašeho návrhu a požadavků zákazníka. Mezi technikami popsanými v  této knize a  tím, do  čeho se lidé pouštějí při vývoji řízeném testy (TDD – Test-Driven Development), existují určité styčné plochy. V jistých ohledech fungují oba procesy dobře společně, přičemž doufáme, že vývojáři softwaru řízeného testy budou mít užitek z kombinace toho nejlepšího z obou těchto světů. Na druhou stranu existuje několik základních odlišností, a to jak z praktického, tak i z ideového hlediska obou disciplín. Kapitola 1 nabízí vysokoúrovňový pohled na testování řízené návrhem (DDT). Kromě toho si stručně představíme projekt Mapplet, s jehož pomocí si budeme v pozdější části knihy vysvětlovat, jak z testování řízeného návrhem vytěžit to nejlepší. Kapitoly 2 a 3 dále srovnávají testování řízené návrhem a vývoj řízený testy. V kapitole 2 si ukážeme, jaké to je, když se k projektu přistupuje pomocí vývoje řízeného testy. Na konci kapitoly snad již budete přesvědčeni o tom, že jistě musí existovat lepší způsob. A ten skutečně existuje! Stejný scénář si projdeme znovu v kapitole 3, avšak tentokrát s použitím testování řízeného návrhem. Výsledky budou mnohem uspokojivější. KAPITOLA 1 Někdo to má pozpátku Když jsme poprvé viděli popis vývoje řízeného testy (TDD), okamžitě nás napadlo: „To je jen pozpátku!“ Rozhodli jsme se tento proces podrobit zkoušce, a proto Matt vyrazil vpřed a nasadil vývoj řízený testy do praxe v rámci svých vlastních projektů, navštěvoval semináře, držel krok s nejnovějšími trendy v této oblasti a tak dále. Jenže nepříjemný pocit, že přece jen není úplně správné řídit návrh pomocí testů, ani tak nezmizel. Kromě toho jsme měli pocit, že vývoj řízený testy je velmi pracný, neboť vývojáře vábí do drahého a v důsledku bezvýznamného štvaní se za svatým grálem 100% pokrytí testy. Ne každý kód se vytváří stejně, přičemž některý kód má z pokrytí testy větší užitek nežli jiný. 1 Musí prostě existovat lepší způsob, jak mít z automatizovaného testování užitek. 1 Myslící algoritmy vs. výplňový kód, jako jsou rutiny pro získávání a nastavování vlastností. 20 Část I: DDT vs. TDD Výsledkem bylo testování řízené návrhem (DDT): s plynutí přímé analýzy a návrhu s agilním, testy řízeným myšlenkovým přístupem. V mnoha ohledech jde o obrácený přístup stojící v pozadí vývoje řízeného testy, což je také důvod, proč jsme si s tímto názvem užili trošku legrace. Přesto to má však někdo i nadále nepochybně pozpátku. Projděte si několik následujících kapitol a sami se rozhodněte, kdo směřuje kupředu a kdo nazpět. V této kapitole se podíváme na vysokoúrovňový přehled testování řízeného návrhem a porovnáme hlavní rozdíly mezi testováním řízeným návrhem a vývojem řízeným testováním. Testování řízené návrhem pokrývá také analýzu a  testování přijatelnosti, a  proto někdy porovnáme testování řízené návrhem s  praxí, která se obvykle používá v  souvislosti s  vývojem řízeným testováním (což je výsadou extrémního programování nebo novějších variant, jako je vývoj řízený testy přijatelnosti – Acceptance TDD). Poté si v kapitolách 2 a 3 projdeme příklad ve stylu „Ahoj, světe!“, u kterého použijeme nejdříve vývoj řízený testy a poté testování řízené návrhem. Zbývající část knihy nabídne testování řízené návrhem v akci s uceleným příkladem založeným na skutečném projektu, kterým je aplikace pro vyhledávání hotelů postavená na heterogenním prostředí s technologií Flex na straně klienta a Javou na straně serveru, přičemž mapy se servírují ze serveru ArcGIS a dotazy se provádějí nad hotelovou databází na bázi XML. Jedná se o netriviální projekt se směsicí technologií a jazyků (což je v současnosti stále častější) nabízející řadu výzev, které testování řízené návrhem řádně prověří. Problémy, které řeší testování řízené návrhem Testování řízené návrhem (metodika DDT) je v jistých směrech odpovědí na problémy, které se objevily u jiných testovacích metodologií, jako je vývoj řízený testy (metodika TDD). V nemenší míře však jde také o odpověď na mnohem větší problémy, k nimž dochází, když se  neprovádí žádné testování (nebo se nenapíšou žádné automatizované testy)  provádí nějaké testování (nebo se napíšou nějaké testy), které je ale celé tak trochu bezcílné a nahodilé  provádí příliš mnoho testování (nebo se napíše příliš mnoho testů, které jsou málo účinné) Poslední situace může vypadat poněkud zvláštně – přece nemůže existovat něco takového jako příliš mnoho testování? Je-li však testování kontraproduktivní nebo repetitivní, mohl by být dodatečný čas strávený testováním promarněný (zákon klesající návratnosti). Existuje přece tolik způsobů, jak stisknout zvonek u dveří, jenže kolik z nich se bude provádět ve skutečném životě? Je skutečně nezbytné prokázat, že zvonek u dveří bude fungovat i 100 metrů pod vodou? Myšlenka stojící za testováním řízeným návrhem spočívá v tom, že testy, které píšete a provádíte, jsou úzce spjaté s požadavky zákazníka, takže strávíte čas testováním pouze toho, co je nutné testovat. Podívejme se na některé z problémů, které byste měli být schopni vyřešit pomocí testování řízeného návrhem. Vědět, kdy je hotovo, je obtížné Při psaní testů je někdy nejasné, kdy máte „hotovo“. Mohli byste tak donekonečna pokračovat v psaní testů všeho druhu, dokud by vaše kódy nebyly stoprocentně pokryté testy. Proč se zde ale zastavo- Kapitola 1: Někdo to má pozpátku 21 vat? Existují přece neprobádané permutace k  otesto vání, na  napsání čekají další testy a  tak pořád dál, až zákazník čekání na dodání produktu vzdá a odejde. Při testování řízeném návrhem jsou vaše testy řízené přímo případy užití a konceptuálním návrhem. Vše je docela systematické, takže budete naprosto přesně vědět, kdy máte hotovo. U klienta, kterého Doug Rosenberg nedávno navštívil, se tým odpovědný za projekt rozhodl, že s testováním přijatelnosti je hotový v okamžiku, kdy jejich timebox signalizoval, že by měli raději začít programovat. Máme podezření, že podobně to funguje docela často. Pokrytí kódu se stalo synonymem pro „kvalitní práci“. Nástroje pro metriky kódu, jako je Clover, poskytují zprávy, které si mohou přehorliví manažeři vytisknout, srolovat a  mlátit jimi vývojáře po hlavě, nepíšou-li dostatek testů jednotek. Je-li však 100% pokrytí kódu prakticky nedosažitelné, mohla by vám být prominuta následující otázka: Proč se o to vůbec snažit? Proč předem prohlašovat, že tohoto cíle nelze nikdy dosáhnout? Naproti tomu jsme chtěli, aby testování řízené návrhem poskytovalo jasný, dosažitelný cíl. „Úplnost“ v testování řízeném návrhem není o všeobecném pokrytí kódu, ale o zajištění, aby byla adekvátně otestována klíčová místa v kódu (logické softwarové funkce). Ponechání testování na později je dražší Stále se můžete setkat se softwarovými procesy, které kladou „testování“ do samostatné fáze až za fáze s požadavky, návrhem a programováním. Je všeobecně známo, že ponechání hledání a opravy chyb v projektu na později zvýší dobu a náklady spojené s jejich odstraňováním. Z hlediska intuice je sice zřejmé, že nemůžete testovat něco ještě dříve, než to začne existovat, ale testování řízené návrhem (podobně jako vývoj řízený testováním a další agilní procesy) vstupuje do zákoutí a štěrbin vývoje a nabízí brzkou zpětnou vazbu pro stav vašeho kódu a návrh. Testování špatně navrženého kódu je těžké Zní to sice samozřejmě, ale kód, který je špatně navržený, bývá strnulý, obtížně adaptovatelný nebo znovupoužitelný v jiném kontextu a plný vedlejších efektů. Naproti tomu testování řízené návrhem přirozeně podporuje kvalitní návrh a dobře napsaný, snadno testovatelný kód. Pro toto všechno se nesmírně obtížně píšou testy. Ve světě vývoje řízeného testy bude vytvořený kód přirozeně testovatelný, protože jste nejdříve napsali testy. Skončíte však s děsivou hromadou testů jednotek pochybné hodnoty, přičemž bude lákavé přeskočit cenné části myšlenkového procesu analýzy a návrhu, neboť přece „kód je návrh“. U  testování řízeného návrhem jsme chtěli testovací proces, který přirozeně podporuje kvalitní návrh a dobře napsaný, snadno testovatelný kód. Každý rozjetý projekt, k němuž se Matt Stephens po čase připojil, byl bez výjimky napsaný tak, že testování kódu bylo velice obtížné (nebo prakticky nemožné). Programátoři se často snaží přidávat testy do svého kódu, načež to rychle vzdají s tvrzením, že testování jednotek je příliš obtížné. Jedná se o obecně rozšířený problém, takže kapitolu 9 věnujeme problému obtížně testovatelného kódu a podíváme se, proč určité styly programování a návrhové vzory činí testování jednotek obtížné. U klienta, kterého Doug Rosenberg nedávno navštívil, se tým odpovědný za projekt rozhodl, že s testováním přijatelnosti je hotový v okamžiku, kdy jejich timebox signalizoval, že by měli raději začít programovat. Máme podezření, že podobně to funguje docela často. Poznámka Každý rozjetý projekt, k němuž se Matt Stephens po čase připojil, byl bez výjimky napsaný tak, že testování kódu bylo velice obtížné (nebo prakticky nemožné). Programátoři se často snaží přidávat testy do svého kódu, načež to rychle vzdají s tvrzením, že testování jednotek je příliš obtížné. Jedná se o obecně rozšířený problém, takže kapitolu 9 věnujeme problému obtížně testovatelného kódu a podíváme se, proč určité styly programování a návrhové vzory činí testování jednotek obtížné . Poznámka Část I: DDT vs. TDD 22 Je snadné opomenout testy na úrovni zákazníka Vývoj řízený testy je již ze své podstaty celý o testování na úrovni podrobného návrhu. Neradi to říkáme, ale vývoj řízený testy ztratil při svém oddělení od extrémního programování cenného souputníka: testy přijatelnosti. Knihy o  vývoji řízeném testy tuto zásadní stránku automatizovaného testování zcela opomíjejí a místo toho hovoří o výběru uživatelského příběhu (neboli požadavku) a okamžitém napsání testu jednotek pro něj. Testování řízené návrhem podporuje psaní testů přij atelnosti i testů jednotek, avšak v jeho jádru jsou testy řadičů, které stojí někde v půli. Testy řadičů jsou „vývojářské testy“, které sice vypadají jako testy jednotek, pracují však na úrovni konceptuálního návrhu (neboli „logických softwarových funkcí“). Poskytují velmi užitečné pojivo mezi analýzou (prostor problému) a návrhem (prostor řešení). Vývojáři bývají samolibí Není nijak neobvyklé, že když vývojáři napíšou pár testů, zjistí, že nedosáhli žádných hmatatelných výsledků, a vrátí se zpět k chrlení neotestovaného kódu. Z naší zkušenosti vyplývá, že zvláště „svatý grál“ 100% pokrytí kódu může u vývojářů vést k pěstování samolibosti. Je-li 100% pokrytí nemožné nebo nepraktické, je 90% v pořádku? A co 80%? Pro tyto třídy jsem testy sice nenapsal, ale vesmír se (zatím) nezhroutil, takže proč se tím vůbec znepokojovat? Je-li cíl nastavený vaším testovacím procesem snadno a jasně dosažitelný, měli byste zjistit, že vývojáři ve vašem týmu se jej snaží docílit s větším smyslem pro účelnost. Tím se dostáváme k poslednímu problému, s nímž si testování řízené návrhem dokáže poradit. Testy někdy postrádají smysl Bezúčelné testování je někdy horší než žádné testování, protože dává iluzi bezpečnosti. To platí jak pro ruční testování (kdy tester postupuje podle popisu testu nebo jen klepe na uživatelské rozhraní a posuzuje produktu k vydání), tak i pro psaní automatizovaných testů (kdy vývojáři nesystematickým způsobem napíšou hromadu testů). Bezúčelné testování jednotek je také problém, protože testy jednotek znamenají více kódu pro údržbu a mohou ztížit úpravu stávajícího kódu, aniž by došlo k narušení testů, které se opírají o příliš mnoho předpokladů o útrobách daného kódu. Psaní samotných testů nadto spotřebovává cenný čas. Znalost toho, proč testujete a  proč píšete konkrétní test jednotky (schopnost stručně vyjádřit, co daný test prokazuje), zajistí, že každý test musí unést svou vlastní váhu. Je nutné ospravedlnit jeho existenci a čas strávený jeho psaním. Účel testů při testování řízeném návrhem je jednoduchý: systematicky prokázat, že návrh splňuje požadavky a že kód odpovídá návrhu. Rychlý přehled metodiky DDT bez ohledu na nástroje Tato část nabízí bleskovou prohlídku procesu testování řízeného návrhem, zhuštěného až na úroveň jednotlivých kroků. Testování řízené návrhem lze sice adaptovat do  libovolného procesu OOAD, původně byl ale navržený pro použití s  metodikou ICONIX Process (agilní proces OOAD, který Kapitola 1: Někdo to má pozpátku 23 používá základní podmnožinu prvků jazyka UML). 2 V této části si ukážeme každý krok v metodice ICONIX Process s odpovídajícím krokem testování řízeného návrhem. Jde o to, že testování řízené návrhem nabízí okamžitou odezvu, při čemž se ověřuje každý krok v procesu analýzy či návrhu. Struktura testování řízeného návrhem Obrázek 1.1 znázorňuje čtyři hlavní artefakty testování: testy jednotek, testy řadičů, testy scénářů a testy obchodních požadavků. Jak je z tohoto obrázku patrné, testy jednotek jsou v podstatě zakořeněné v prostoru návrhu/řešení/implementace. Programátoři je píšou a „vlastní“. Nad nimi jsou mezi prostorem analýzy a prostorem návrhu vložené test y řadičů, které pomáhají poskytovat přemostění mezi oběma prostory. Testy scénářů náleží do prostoru analýzy. Jedná se o ručně specifikované testy představující rozvinutí optimistických/pesimistických permutací daného případu užití a obsahující pokyny ve formě jednotlivých kroků, podle kterých mají testeři postupovat. Jakmile se s procesem seznámíte a organizace bude této myšlence více nakloněna, vřele doporučujeme založit celkové integrační testy na specifikacích testů scénářů. A nakonec, testy obchodních požadavků mají téměř vždy podobu ručních specifikací testů. Usnadňují „kontrolu zdravým rozumem“ před zapečetěním produktu pro vypuštění do divočiny. Testy obchodních požadavků Testy scénářů Testy řadičů Testy jednotek Analýza – „Prostor problému“ Návrh – „Prostor řešení“ Obrázek 1.1: Čtyři hlavní příchutě testování v DDT Testy se liší granularitou (tj. množstvím kódu, který každý test ověřuje) a počtem automatizovaných testů, které jsou ve skutečnosti napsané. Toto ukazuje obrázek 1.2. Z obrázku 1.2 je rovněž patrné to (pokud jsou vaše popisy testů scénářů implementované také jako automatizované integrační testy), že každý případ užití pokrývá právě jedna testovací třída (ve skutečnosti se jedná o jeden testovací případ pro každý scénář případu užití; více o tom ale až později). Při použití metodiky ICONIX Process se případy užití rozdělí do řadičů, přičemž každý test řadiče (dle očekávání) pokrývá právě jeden řadič. Řadiče se pak rozdělí na samotné funkce či metody kódu s tím, že významnější metody získají jednu či více metod testu jednotky. 3 2 V této knize je obsažen dostatek informací o metodice ICONIX Process k tomu, abyste mohli rozjet testování řízené návrhem ve vlastních projektech. Pokud se však chcete o metodice ICONIX Process dozvědět více, sáhněte po doprovodné knize s původním názvem Use Case Driven Object Modeling with UML: Theory and Practice. 3 Možná vás zajímá, jak se pozná, zda danou metodu pokrýt testem jednotky, nebo testem řadiče? Jednoduše: nejdříve implementujte testy řadiče, a zůstane-li nějaká „významná“ část kódu nepokrytá, tak zvažte, zda jí nepřidělit test jednotky. Více se o těchto místech rozhodování dozvíte v kapitolách 5 a 6. Část I: DDT vs. TDD 24 Pravděpodobně jste se již setkali s tradičním modelem vývoje softwaru znázorněným ve tvaru písme


       
Knihkupectví Knihy.ABZ.cz - online prodej | ABZ Knihy, a.s.
ABZ knihy, a.s.
 
 
 

Knihy.ABZ.cz - knihkupectví online -  © 2004-2018 - ABZ ABZ knihy, a.s. TOPlist