UNIVERZITA KOMENSKÉHO V BRATISLAVE FAKULTA MATEMATIKY, FYZIKY A INFORMATIKY

Transcription

1 UNIVERZITA KOMENSKÉHO V BRATISLAVE FAKULTA MATEMATIKY, FYZIKY A INFORMATIKY WEBOVÁ VÝUKA PROGRAMOVANIA V C++ POMOCOU JEDNOTKOVÉ- HO TESTOVANIA BAKALÁRSKA PRÁCA 2016 Viliam Vakerman

2 UNIVERZITA KOMENSKÉHO V BRATISLAVE FAKULTA MATEMATIKY, FYZIKY A INFORMATIKY WEBOVÁ VÝUKA PROGRAMOVANIA V C++ POMOCOU JEDNOTKOVÉ- HO TESTOVANIA BAKALÁRSKA PRÁCA 2016 Viliam Vakerman

3 PHOTOCOPY: ZADANIE

4 Abstrakt v štátnom jazyku: Kľúčové slová: Abstract: Key words:

5 Poďakovanie Touto cestou by som rád poďakoval školiteľovi diplomovej práce prof. Františkovi Gyarfášovi. za odborné rady a podporu pri výbere bakalárskej témy.

6 Zoznam obrázkov Zoznam tabuliek Zoznam skratiek a značiek Slovník termínov

7 Úvod Cieľom bakalárskej práce je vytvoriť interaktívne prostredie pre výuku programovania v jazyku C++ vo forme webovej aplikácie. Táto aplikácia umožní editovanie jednoduchých zdrojových kódov cvičení, ako aj vytváranie, zbiehanie a vyhodnocovanie jednotkových testov riešených metód v oknách webového prehliadača. Aplikácia zabezpečí kompiláciu tvoreného kódu na serveri, spojenie s príslušnými testami a testovacou knižnicou, vytvorenie a zbiehanie testovacej aplikácie na virtuálnom serveri. Práca zahŕňa základné nástroje na administráciu systému - správu používateľov a ich prístupových práv k zdrojovým kódom. Systém bude realizovaný pomocou technológií/ nástrojov: PHP (framework), MySQL, HTML, CSS, JavaScript (jquery, Bootstrap), kompilátor C++, knižnica pre unit testing v C++, virtuálny server. Bakalárska práca je zložená z troch hlavných častí. Prvá kapitola je teoretická a zaoberá sa definovaním základných pojmov ako unit testing framerowky a test driven development. Druhá kapitola pojednáva o praktickom návrhu samotnej aplikácie a delí sa na dva celky: Návrh webovej aplikácie a implementácia. V prvej časti druhej kapitoly autor práce navrhuje konkrétne kontúry webovej aplikácie, kde analyzuje použité technológie a architektúru aplikácie. Druhá časť druhej kapitoly je venovaná samotnej implementácii aplikácie. V tejto časti sú definované základné charakteristiky, funkcionality a nastavenia virtuálneho prostredia. Poslednú kapitolu práce tvorí záver, ktorý zhŕňa informácie o samotnej webovej aplikácii. Analyzuje jej pozitíva a následné vylepšenia pre jej budúci vývoj. 7

8 1 Teoretické východiská práce Teoretická čast bakalárskej práce pojednáva o dvoch hlavných východiskových metódach a technológiach, konkrétne o Unit testing framework a Test driven development. Test driven development je prístup, akým je softvér vyvíjaný. Prostredníctvom tejto metodológie budú používatelia aplikácie schopní splniť úlohy a zároveň si ich aj otestovať. Unit testing frameworky sú určité vývojové postupy vďaka ktorým sú tvorené testy spolu s vývojom softvéru. V praktickej časti bakalárskej práce bude použitý Google Test unit testing framework. Z toho dôvodu je dôležité objasniť funkcionalitu a význam použitej technológie. Bakalárska práca ďalej analyzuje unit testing z pohľadu kvality, špecificky z perspektívy zodpovednosti, spoľahlivosti a používateľnosť. Ďalšia podkapitola elaboruje na tému unit testing frameworkov najčastejšie využívaných v dnešnej dobe. Architektúra xunit frameworkov je podrobne rozbraná v nasledujúcej podkapitole spolu s najčastejšie a vyskytujúcimi príkladmi. Posledná podkapitola sa podrobne venuje téme využitia Google test frameworku a jej výhodám oproti iným testovacím frameworkom. Google test framework bude následne demonštrovaný v praktickej časti bakalárkej práce. 1.1 Test Driven Development Test Driven Development [4] (ďalej TDD) alebo v slovenskom jazyku: vývoj riadený testami sa radí medzi agilné metodológie vývoja softvéru. Základnou myšlienkou TDD je, že testy sú napísané skôr ako kód samotný. Softvér sa vyvíja po malých krokoch, pričom sa využíva unit test framework. Tento framework poskytuje okamžitú odozvu už aj na menšie zmeny. Využitím stále sa opakujúcich krokov sa dosiahne zefektívnenie celého vývoja. Test driven development akoby fungoval obrátene od klasických metód. Prvým krokom nie je písanie kódu, ako by sa mohlo zdať, ale definuje sa funkcionalita a následne sa kreuje test. tento test je tak schopný ihneď otestovať vopred určenú funkcionalitu. Po tomto procese sa začína písať samotný kód, ktorý sa neskôr upraví. Unit test framework [1] poskytuje mechanizmy zabezpečujúce zbiehanie testov. Vývojári sa preto môžu sústrediť na písanie kódu so špecifickou logikou. Architektúra xunit frameworkov je portovanateľná na väčšinu súčasných programovacích jazykov. TDD je možné charakterizovať ako jeden z najsignifikantnejších postupov v rámci metodológie vývoja softvérov. Unit testing frameworky, ktoré boli definované v úvodnej časti kapitoly sú základným pilierom pre TDD. Podľa Davida Astelsa, Test- Driven Development je štýl v ktorom: Je zachovaná dôkladná sada programátorských testov Žiaden kód, ktorý nie je otestovaný nemôže ísť do produkcie Test sa píše ako prvý Test determinuje aký kód je potrebný Podľa Kenta Becka môže byť všeobecný TDD cyklus opísaný nasledovne: 1. Napíšte test: Porozmýšľajte nad tým, ako by ste chceli aby vyzerala konkrétna 8

9 operácia. Je to ako písať príbeh. Vymyslite podobu rozhrania. Zakomponujte všetky elementy do príbehu, ktoré sú nevyhnutné k tomu, aby ste prišli k správnej odpovedi. 2. Spustite testy. Ak je jednoduché a čisté riešenie jednoznačné, napíšte to. Hlavným pravidlom je aplikovať Occamovu britvu a využiť to najjednoduchšie riešenie. 3. V poslednom kroku sa presvedčte, že test bol úspešný a refraktorujte kód. Hlavnou úlohou TDD je vytvoriť čo najkvalitnejší a najoptimálnejšie funkčný produkt. Medzi hlavné výhody využitia tejto stratégia patrí ich flexibilita pri možných zmenách vývoja systému. Ich pozitívom je taktiež schopnosť púšťania testov vo veľkom množstve. Tieto testy tak dookola testujú a overujú funkcionalitu, ktorú si vývojár určil. testy sú schopné chybu detekovať v prípade, ak prišiel zásah a chybu spôsobil. V prípade, že sa zmenia požiadavky voči funkcionalite, princíp funguje rovnako. Ak nastane takáto situácia, riešením je napísať nový test alebo upraviť pôvodný. To isté platí aj v prípade kódu. Testy následne rýchlo overia a vyhodnotia, či zmeny viedli z disfunkcií. Ako bolo vyššie uvedené, práve princíp malých krôčkov umožňuje ľahšiu indikáciu chýb a ich následné vyriešenie. Test driven development však spôsobuje aj mnohé problémy. Pri používaní TDD je nutné uvažovať o tom, že chyby sa môžu nachádzať ako v testoch, tak v kóde. Testy síce šetria čas v istých fázach programovania, no na druhej strane množstvo kódu, ktoré je potrebné napísať sa úmerne zvyšuje. Ďalším obmedzením je zlá testovateľnosť istých častí programu, ako napríklad užívateľského rozhrania. Je nutné uvedomiť si, že TDD nemôže nahradiť všetky typy testovania. 1.2 Unit testing framerowky Unit testing frameworky sú charakterizované ako vývojové postupy, prostredníctvom ktorých sú vytvárané testy spolu so samotným vývojom softvéru. Ich hlavnou úlohou je testovať funkcionalitu vytvorenej aplikácie. V nasledujúcej kapitole bude bakalárska práca pojednávať o všeobecnom prehľade unit testing framework ako aj o výhodách ich použitia. S unit testom sa stretol aj úplný začiatočník programátor. V prípade, ak programátor začiatočník napísal len niekoľko riadkov kódu, je vysoko pravdepodobné že sa s unit testom stretol. Toto je samozrejme príklad toho najelementárnejšieho unit testu. Tie najrozvinutejšie aplikácie obsahujú veľké sady testov, ktoré sa spúšťajú opakovane a v rôznych fázach vývoja aplikácie. Unit testing framework je možné charakterizovať ako softvérový nástroj podporujúci vytváranie a spúšťanie unit testov. Je dôležité poznamenať, že unit testing framework nemusí slúžiť len ako testovací nástroj aj ako vývojový nástroj. Čo sa týka fázy vývoja aplikácie, unit testing frameworky je možné využiť v rôznych fázach, od vývoja, po architektúru, implementáciu, debuggovanie či optimalizáciu. 9

10 Na obrázku č. 1 je demonštrovaná schéma aplikácie produktu a unit test framework ako taký. Ako je z obrázku vidieť, unit testy sú vyvíjané spolu s produkčným kódom. Rozdielom však je, že unit testy nie sú zahrnuté do konečného produktu, rsp. do jeho kódu. Obr č.1 : Aplikácia produktu a unit test framework schéma Softvérové objekty, ktoré sú medzi sebou prepojené sa dajú pokladať za stavebný kameň aplikácie. Testovanie sa zväčša deje mimo aplikácie a tým pádom sa objekty dajú testovať samostatne. Unit testy fungujú tiež na princípe softvérových objektov, v tomto prípade však pracujú v samotnom vnútri unit testing frameworku. Tým pádom samotný kód nemá v sebe zahrnuté testy a je ľahšie čitateľný. Unit testing frameworky môžu byť použité v rámci testovania jednoduchej funkcionality ale aj na testovanie zložitejších a štrukturovanejších architektúr. Výhodou oproti vývoju samostatných testov je efektivita, jednoduchosť a dôslednosť. Pri použití unit testing frameworkov si vývojár v ktoromkoľvek štádiu môže overiť samostatné vývojové kroky. Unit test teda sleduje správanie produkčného kódu ako takého. Ak je využitý test správne, dokáže skontrolovať nastavenie prostredia a podať správu o správnosti výsledku. Ako opisuje vo svojej knihe Unit Test Frameworks Paul Hamill, unit tesing frameworky je možné kategorizovať do dvoch skupín: black box a white box. Toto rozdelenie je ovplyvnené prístupom do samotného mechanizmu testovania. Black box je možné charakterizovať ako funkcionálny test. Jeho úlohou je spustiť program a skontrolovať kód ktorý sa z neho vráti. Ako indikuje už samotný názov, test je nazvaný black box, pretože sa nesústredí na to, ako je program vlastne napísaný. Termín white box je možné charakterizovať ako štrukturálny test. V tomto prípade test už má prístup do vnútra samotného kódu a môže testovať jeho štruktúru. Dôležitým faktorom je však aj rozdelenie private vs. protected member. Je nutné myslieť na fakt, že množstvo programovacých jazykov ktoré patria do skupiny objektovo orientovaných zabraňuje triedam zvonku vstupovať do procesu. Z tohto hľadiska unit testy často testujú len verejné objekty, ktoré sa majú testovať. Práve tento fakt je dôvodom, prečo vzniká čoraz viac dizajnu objektov s minimálnymi faktormi skrytého správania sa. Ako uvádza Paul Hamill, rozdiel medzi acceptance testami a programátorskými testami ako takými je časové hľadisko. Programátorské testy sú tvorené počas doby trvania písania samotného kódu. Acceptance testy nemusia byť tvorené a charakterizované iba programátorom. Do tohto procesu sa môžu zapojiť manažéri produktoví alebo manažéri 10

11 kvality. Tieto testy reagujú na samotný výstup, respektíve na požiadavky zadávateľa alebo používateľa. Programátorské testy sa sústreďujú na nízko-úrovňové kódy. Výhodou unit testov je fakt, že sa dokážu etablovať do oboch spôsobov testovania Unit testing a kvalita V rámci zabezpečenia kvality sa ako prvý krok využíva spustenie sady unit testov. Unit testing frameworky sú často využívané v automatizovaných testovacích softvéroch, pretože dokážu zabezpečiť ich kvalitu. Táto fáza zabezpečenia kvality plnohodnotne odštartuje po otestovaní unit testami. V rámci kvalitatívneho pohľadu na spúšťanie sady unit testov exituje niekoľko výhod: 1. spoľahlivosť: v momente keď kód opúšťa vývojára, testy garantujú jeho spoľahlivosť. Vďaka booleovskému princípu sú možné len dve riešenia: pravda alebo nepravda, respektíve úspech alebo zlyhanie. Úspech testu signalizuje správnosť vývojárovho myslenia v rámci funkcionality. 2. zodpovednosť: Kód nemôže ostať v stave, kedy sú v ňom obsiahnuté zlé unit testy. 3. použiteľnosť: Je nutné uvedomiť si, že unit testy nie sú možné nahradiť inými typmi testovania. Aj keď je kód otestovaný unit testami, môže nastať prípad, že jeho použiteľnosť ostáva nenaplnená. V takom prípade je nutné využitie stres testov, ktoré bývajú separované od unit testov. Pri diskusií o parametroch kvality v rámci unit testingu je nutné pripomenúť, že môžu nastať situácie, ktoré nie je možné otestovať. Z praktického hľadiska môže nastať situácia, kedy sa objaví funkcionalita, ktorú nemožno otestovať unit testom. Ide o interakcie, reakcie medzi systémovými akciami, kedy je nutné zistiť spätnú väzbu s konečným užívateľom. Ako uvádza vo svojej knihe Unit Test Frameworks Paul Hamill [1][Strana 5], test nie je schopný ľudského úsudku, ktorý je častokrát veľmi dôležitý a smerodajnejší ako test samotný. 1.3 Frameworky jednotkového testovania v dnešnej dobe V roku 1999 Kent Beck publikoval unit test framework pre smalltalk. Architektúra SUnit alebo SmalltalkUnit reprezentovala ideálnu podobu, chytrí balans medzi jednoduchosťou a užitočnosťou. Po triumfálnom využití unit testing frameworkov prišiel Enrich Gamma s dnes už veľmi populárny framework JUnit-u. Gammovi sa podarilo preportovať už existujúci SUnit do Java programovacieho jazyka. JUnit tak spôsobil vlnu vzniku ďalších frameworkov akými sú PyUnit, CppUnit, XMLUnit a ďalšie. Tieto frameworky sa dostali do povedomia ako xunit rodina nástrojov. Ich výhodou je, že sú voľne dostupné a voľne šíriteľné(open source software). 11

12 1.4 Architektúra xunit frameworkov Všetky xunit frameworky zdieľajú základnú architektúru a funkcionalitu. Líšia sa v ich implementačných detailoch, ale nasledujú ten istý model a všeobecne obsahujú rovnaké kľúčové triedy a koncepty. V nasledujúcej časti bakalárska práca bude pjednávať o jednotlivých triedach xunit frameworkoch: Asercie, TestCase, TestFixture a TestSuite Asercie Jedným z cieľov automatického jednotkového testovania je aby boli testy samotestovateľné, to znamená, že nieje potrebný manuálny zásah pri interpretácii výsledkov testov. Je to dosiahnuteľné použitím asercií, ktorých návratová hodnota je boolean(úspech, neúspech), a teda výsledok môže byť interpretovaný počítačom. Najbežnejšie asercie sú tie, ktoré vyhodnocujú jeden výraz alebo porovnávajú dve hodnoty TestCase Trieda TestCase je jedna z najpouživanejších tried pri práci s xunit frameworkom. Najjednoduchší spôsob ako vytvoriť triedu jednotkového testu je odvodením od triedy TestCase TestFixture Trieda TestFixture vytvára testovacie prostredie v ktorom sa testy dajú spúšťať opakovane v tích istých podmienkach. Aby boli zabezpečené rovnaké podmienky pri vyhodnocovaní jednotlivých testov používa trieda TestFixture metódy setup a teardown. Tieto metódy sú implementované do testovacej triedy xunit frameworkov TestSuite Trieda TestSuite slúži na zhromaždovanie a vykonanie sady testov v rámci jedného zbehnutia. Keď sa spustí testovacia trieda odvodená od TestCase vyvolajú sa všetky jej testovacie metódy. Triedy testov a ich sady sú pridávané do ďaších sád. Takýmto spôsobom sa dajú vytvoriť a spustiť väčšie hierarchie testov. 1.5 Unit testing frameworky pre C++ Pre programovací jazyk C++ existuje niekoľko unit testing frameworkov. Medzi najčastnejšie využívané patria Cpp Unit, Bookt. Test či Unit ++. Pre účely bakalárskej práce bude autor pracovať s Google Test. 1.6 Google Test Google test [5] patrí do kategórie unit testing knižnice pre jazyk C++. Tak ako iné unit testy, je založený na xunit architektúre. Google Test môže byť skompilovaný na niekoľko Windows alebo aj POSIX platforiem s minimálnymi modifikáciami, pričom testy môžu bežať osve alebo všetky naraz. Unit testing framework Google test bol oficiálne vydaný v auguste 2016, tým pádom je veľmi málo odbornej literatúry, ktorá by sa danej problematike venovala. Informácie sú dostupné len na stránkach ako github.com alebo ibm.com. Z tohoto dôvodu bolo 12

13 pre autora práce obtiažne nájsť dostupný materiál, ktorý by podrobnejšie charakterizoval onen uni testing framework. Google predstavil vlastný koncept klasifikácie typov testov: malé, stredné a veľké testy. 1. Malé testy: Hlavnou otázkou, ktorú si tento test pokladá je zistenie funkcionalitu kódu. Robí kód to, čo robiť má? Malé testy sa najčastejšie vyskytujú ako automatizované a kód je vykonávaný len v malých moduloch alebo funkciách. Dôraz je v tomto teste kladený na typické funkčné problematiky, poškodenie dát či chybových stavov. Tento konkrétny druh testov sa najčastejšie vyskytuje ako krátkotrvajúci, spúšťajúce sa do pár sekúnd. Malé testy si vo všeobecnosti vyžadujú skušobné prostredie na to, aby mohli bežať a byť otestované. Taktiež sa využívajú pre diagnostiku konkrétnych chýb a zlyhaní. 2. Stredné testy: Hlavnou otázkou je, či v rámci sady blízkych funkcií spolupracujú tieto funkcie navzájom tak, ako je predpokladané. Testy sú najčastejšie automatizované a zahŕňajú dve alebo viac vzájomne ovplyvňujúcich sa funkcií. Dôraz sa kladie na testovanie interakcií medzi vlastnosťami ktoré sa navzájom volajú alebo interagujú medzi sebou navzájom. Softvéroví inžinieri riadia vývoj týchto testov v počiatkoch produkčného cyklu pred tým ako sú jednotlivé funkcie dokončené. Vývojári sú v tomto procese zapojení do písania, ladenia chýb a udržiavania testov. 3. Veľké testy: Tieto testy reprezentujú skutočný užívateľský scenár s užívateľskými dátami. V prípade veľkých testov existujú obavy v otázke integrácie funkcií. Veľké testy majú tendenciu byť viac výsledkovo-riadené, overovať si, či softvér napĺňa požiadavky používateľov. Na tematiku Google test je možné pozrieť sa z troch uhlov, ktoré odzrkadľujú jeho kvalitatívne vlastnosti. Spoľahlivosť: test spolahlivosti zlyháva v prípade, že zlyhal testovaný kód alebo aj vtedy, keď zlyhá samotný proces testovania. Laicky povedané, ak kód padne test je neúspešný. Pružnosť: test by nemal zlyhať v prípade, ak neprejde TestCase. Test zlyhá iba v prípade, že je v testovanom kóde implementovaná zlomová zmena. Presnosť: Ak test zlyhá, presná chyba bude lokalizovaná a oznámená testerovi. Tento typ testu nefunguje ideálne s funkciou, ktorá sa spolieha na reťazec ako vstupný parameter. Existuje niekoľko dobrých dôvodov prečo použiť pri vývoji práve Google Test framework. Pri obdobných typoch testov sa vývojári stretávajú s problémami týkajúcich sa operačnej pamäte. Tieto problémy nastávajú len pri niektorých zbehnutiach. Google Test poskytuje pre riešenie podobných situácií výbornú podporu. Nespochybniteľnou výhodou je, že pomocou Google frameworku je možné opakovať rovnaký test niekoľko tisíckrát. Pri prvom náznaku poruchy je automaricky vyvolaný debugger. Tieto akcie sa dejú prostredníctvom dvoch spínačov v príkazovom riadku: --gtest_repeat= gtest_break_on_failure. Na rozdiel od mnohých iných testovacích frameworkov, Google test framework 13

14 obsahuje vstavané tvrdenia (asserts), ktoré sú nasaditeľné do softvéru kde je spracovanie výnimiek znemožnené. V takom prípade to znamená, že tvrdenie (assert) môže byť v deštruktoroch použitý bezpečne. Ďalšou výhodou je jednoduchosť pri spustení testov. Pre spustenie stačí zavolať RUN_ALL_TESTS makro. Tým pádom nie je potrebné vytvoriť a odvodiť separátnu runner class pre spúšťanie testov. Práve táto funkcia robí Google Test špecifickým na rozdiel od ostatných frameworkov ako napríklad CppUnit. Generovanie XML reportu (Extensible Markup Language) je taktiež jednoduchým procesom. Pre vykonanie tohto úkonu je potrebné využiť nasledovnú funkciu: --gtest_output= xml:<file name>. ( library/au-googletestingframework.html) Google test je v súčastnosti využívný viacerými prestížnzmi projektami ako sú Chromium, teda Chrme browser, Open CV či Gromacs Fixture testing Fixture testing je strategicky dôležitý v rámci počítačového kódu, pretože povoľuje testovanie manažmentu času a pamäte. Ak tieto oblasti chýbajú, môžu vznikať chyby a kód sa stane nekompatibilným alebo v horšom prípade sa nespustí vôbec. Google Test môže špecificky spracovať a spustiť tento konkrétny typ testu. Ak tak urobí, môže spoznať presný typ fixture testu, ktorý je požadovaný. Fixtury sú v rámci Gogle Testov považované za triedy a môžu byť inštancované ako jeden. Existuje však niekoľko detailov, v rámci ktorých fixtury fungujú: Inicializácia alebo alokácia zdrojov je možná v koštruktore alebo v SetUp metóde Dealokácia zdrojov v teardown alebo v deštruktore rutiny. V prípade, ak je ptrebná výnimná v rámci manipulácie, proces je možné spraviť len prostredníctvom TearDown kódu, pretože využitím výnimky môže dôjsť k nedefinovateľnému správaniu Makrá asercií Googlu môžu vyvolať výnimku v platformách, v ktorých sú pre budúce verzie dostupné. z tohoto dôvodu je optimálnym a efektívnym nápadom využiť asercie marka v TearDown kóde z dôvodu lepšej udržateľnosti. Rovnaký test fixtury nie je použitý v rámci viacerých tesotv. Pre kadžý nový unit test, framerowk vytvára nový test fixture. 14

15 1.7 Zhrnutie kapitoly Teoretická časť bakalárskej práce pojednávala o hlavných technológiách a metodológiach, ktoré budú využívané v rámci praktickej časti záverečnej práce. Prvým technologickým prístupom analyzovaným v úvodnej časti práce je Test driven development. Tento inovatívny prístup je založený na princípe prvotného testovania a následnej tvorby kódu. Flexibilita, minimalizovanie času a zdrojov pri vývoji sú nespochybniteľnými výhodami Test driven development prístupu. Unit testing frameworky sú vývojové postupy na základe ktorých sú tvorené testy spolu s vývojom softvéru. Z množstva unit testing frameworkov pre jazyk C++ si autor bakalárskej práce vybral najmodernejšiu technológiu Google Test. Okrem Google Test frameworku sa práca venuje najčastejšie využívaným frameworkom využívaným v dnešnej dobe. Architektúra xunit frameworkov je podrobne analyzovaná v nasledujúcej podkapitole. Úlohou prvej kapitoly bakalárskej práce bolo vysvetliť teoretické pozadie aplikovanej časti a zanalyzovať jednotlivé metodólógie a postupy, ktoré v nej budú použité. Je dôležité vedieť operovať s odbornou terminológiou pred začatím vývoja samotnej aplikácie. Autor taktiež využíva najmodernejšie technológie vo forme Google testovania, ktorá bola zverejnená v auguste 2016, teda len niekoľko mesiacov po začatí písania práce. 15

16 2 Návrh aplikácie 2.1 Funkcionalita aplikácie a jej požiadavky Cieľom je vytvoriť webstránku, ktorá zjednoduší proces výučby predmetov jazyka C++ Hlavné funkcie aplikácie: Registrácia v rámci aplikácie, vztvorenie identity Interaktívne prostredie 2.2 Architektúra aplikácie 16

17 Bibliografia [1] Hamill, P. (2004). Unit test frameworks. Sebastopol, CA: O Reilly. [2] Astels, D. (2003). Test-driven development: A practical guide. Upper Saddle River, NJ: Prentice Hall PTR. [3] Langr, J., & Swaine, M. (2013). Modern C programming with test-driven development: Code better, sleep better. Dallas, TX: The Pragmatic Bookshelf. [4] Beck, K. (2002). Test Driven Development: By Example. Addison-Wesley Professional. [5] Arpan, S., Google C++ Testing Framework, [online] developerworks/aix/library/au-googletestingframework.html pristupované