Share
Testarea unităților este relativ nouă pentru proiectele ActionScript. Deși FlexUnit a fost în jur de ceva timp, nu a fost intuitiv să se înființeze și au existat o mulțime de inconsecvențe cu documentația. Lucru pentru noi, FlexUnit este acum încorporat în Flash Builder 4. Deși documentația este încă redusă, acest tutorial va fi un bun primer pentru instalarea unei suite de testare, trecând peste câteva exemple de test de unitate și arătând modul de rulare / analiză a acestora.
Pentru cei care nu sunteți familiarizați cu testarea unităților, să vedem ce trebuie să spună Wikipedia
În programarea pe calculator, testarea unității este o metodă de verificare și validare a software-ului în care programatorul câștigă încrederea că unitățile individuale de cod sursă sunt potrivite pentru utilizare ... Testele de unitate sunt de obicei scrise și executate de către dezvoltatorii de software pentru a se asigura că codul corespunde designului său și se comportă așa cum a fost intenționat . - wikipedia
În acest tutorial vă voi arăta cum am creat câteva teste simple de unitate pe cadrul meu Flash Camo. Va trebui să descărcați o copie a Flash Builder 4 (în Beta chiar acum) pentru a urmări. De asemenea, veți dori să descărcați cea mai recentă versiune de Flash Camo (2.2.1) de aici.
Să creăm un nou proiect numit UnitTestIntro.
Va trebui să plasăm SWC Flash Camo într-un libs / centrele de lucru inteligentă dosar în cadrul proiectului nostru:
În cele din urmă, va trebui să ne spuneți proiectul nostru unde să găsiți SWC-ul nostru, faceți clic-dreapta pe proiect și intrați în proprietățile acestuia. Accesați Calea de construire ActionScript și selectați fila Calea Bibliotecii. Faceți clic pe Adăugați directorul SWC și îndreptați-l către directorul lib / swcs.
Acum, că avem totul setat, putem începe să facem niște teste unitare de bază. Este important să rețineți că nu puteți efectua testarea unității direct într-un proiect Flex Library. Aceasta nu este o problemă pentru acest proiect, dar dacă doriți să testați o bibliotecă de cod, ceea ce fac de obicei este să creați un nou proiect (așa cum facem aici), apoi să conectați cele două proiecte împreună și să creați toate testele din noul proiect.
Dacă nu lucrați într-un proiect Flex Library și doriți să vă testați codul, puteți crea doar testele dvs. în același proiect. Aș sugera să țineți cele două separate, astfel încât să puteți vedea în mod clar ce sunt clasele de test și care sunt clasele reale. O să intrăm în acest lucru mai târziu, când veți vedea cum am stabilit testul.
Înainte de a începe ceva, îmi dau o clipă să-mi dau seama exact ce voi face. Acest lucru este foarte important atunci când se stabilesc teste unitare. Acest tip de dezvoltare se numește Dezvoltare pe baza de test. Cred că văd o altă definiție:
Dezvoltarea bazată pe dezvoltare (TDD) este o tehnică de dezvoltare a software-ului care utilizează iterații de dezvoltare scurte pe baza unor cazuri de testare pre-scrise care definesc îmbunătățirile dorite sau noi funcții. Fiecare iterație produce codul necesar pentru a trece testele iterației. În cele din urmă, programatorul sau echipa refacă codul pentru a se potrivi modificărilor. Un concept cheie TDD este că pregătirea testelor înainte de codificare facilitează schimbările rapide de feedback. - wikipedia
Deoarece acesta este un scurt intro, vom folosi o bibliotecă de cod existentă pentru a testa. Cu toate acestea, pe măsură ce creați propria aplicație, trebuie să scrieți teste de-a lungul drumului pentru a valida faptul că codul funcționează și că orice modificare / refactorizare nu încalcă implementarea codului. Iată o schemă a testelor pe care le vom efectua:
Dacă sunteți nou la Flash Camo, puteți verifica intro-ul pe care l-am scris (partea 1 și partea 2), dar puteți să faceți acest tutorial cu ușurință fără să știți cum funcționează cadrul. Din nou, aceasta este pur și simplu va fi o bibliotecă de cod pentru care trebuie să încercăm.
Acum, când avem un plan de testare, să facem primul nostru test. Faceți clic dreapta pe proiectul dvs. și selectați New> Test Case Case
Acum vi se va prezenta expertul de creatie. Ar trebui să fie familiar tuturor celor care au creat o clasă în Flex / Flash Builder înainte. Iată cum arată fereastra:
Să vorbim despre câțiva dintre câmpurile noi din expert. Putem începe cu faptul că Superclass este deja completat pentru noi: flexunit.framework.TestCase. Nu puteți schimba acest lucru și probabil că nu ar trebui. Tot ce se întâmplă este extinderea clasei de test de bază de la Unitatea de testare. În continuare veți vedea câteva casete de selectare pentru generarea de coduri. Lăsați toate acestea verificate în mod prestabilit. În sfârșit, există un câmp pentru clasa pe care dorim să o testăm.
De vreme ce vom încerca să testăm CamoPropertySheet-ul Flash Camo, să umplem următoarele valori în formularul:
Nume: Clasa CamoPropertySheetTest de testat: camo.core.property.CamoPropertySheet
Iată o imagine pe ecran a modului în care am stabilit acest lucru:
Hit terminat și ar trebui să ne pregătim primul test pentru a adăuga un cod.
Să aruncăm o privire la codul creat de Flash Builder pentru noi:
Începem prin a avea o proprietate privată numită classToTestRef care este setat la valoarea CamoPropertySheet. Acest lucru permite testului să creeze o instanță a acestei clase și forțează compilatorul să o importe atunci când executăm testul.
Următoarea metodă importantă este înființat. Aici vom crea o instanță a clasei noastre de testare, o vom configura și vom avea grijă ca totul să fie gata pentru a efectua un test.
Ultima metodă aici este dărâma. Aici vom distruge instanța clasei de test atunci când testul este complet. Acest lucru este foarte important atunci când efectuați mai multe teste.
S-ar putea să fi observat la sfârșitul clasei o altă metodă numită testSampleMethod care este comentat. Acesta este un exemplu despre cum ați stabili un singur test.
Fiecare test va fi o metodă pe care o adăugăm la această clasă. Când rulați unitatea de testare a unității, acesta va apela automat toate metodele noastre dinamic, desigur începând cu setUP și terminând cu dărâma.
Acum că avem o înțelegere de bază a configurației TestClass, să ne uităm la rularea acesteia.
Înainte de a putea executa acest lucru, vom avea nevoie de cel puțin un test. Să ne despărțim testSampleMethod pentru acest exemplu.
Odată ce ați dezactivat testSampleMethod să faceți clic dreapta pe proiectul nostru și să selectați Run As> Execute FlexUnit Test.
Acum ar trebui să vedem următoarea fereastră care ne determină să alegem ce test să ne dăm.
După cum vedeți, acesta este setat pentru momentul în care avem multe de testat, dar pentru moment avem doar un testSampleMethod pentru a rula. Faceți clic pe Selectați toate și apoi pe OK.
După ce testul este rulat, browserul Web va apărea cu următoarea pagină:
Dacă reveniți la Flash Builder veți vedea și acest lucru în panoul Rezultate FlexUnit:
Vedeți cât de ușor a fost aceasta? Am efectuat primul nostru test de unitate și deja avem o singură eroare. Înainte de a trece la rezolvarea acestei erori, să vorbim despre aceste două ferestre.
Pagina web deschisă ar trebui să se închidă automat, dar uneori nu o face. Acesta este un SWF simplu care efectuează testele noastre în FLash și scoate niște date pe care Flash Builder le citește pentru a afișa rezultatele finale ale testului. Puteți ignora această pagină web în cea mai mare parte.
Panoul Rezultate FlexUnit este locul în care vor fi afișate toate rezultatele, precum și un loc care vă permite să organizați și să filtrați feedback-ul testului. Vom trece peste acest lucru mai târziu în tutorial când avem de fapt ceva de testat.
Înainte de a putea intra într-adevăr într-o testare, va trebui să configurați clasa de test. să adăugăm următorul cod la înființat metodă:
var xml: XML =; rawCSS = xml.toString (); foaie = noul CamoPropertySheet (); sheet.parseCSS (rawCSS);
De asemenea, vom avea nevoie să configurați câteva proprietăți:
fila privată de var: CamoPropertySheet; private var rawCSS: String;
Iată ce se întâmplă în această configurație: pentru ca noi să putem testa CamoPropertySheet, vom avea nevoie de un CSS ca un șir. În mod normal, aș fi încărcat în CSS dintr-un fișier extern, dar din moment ce facem un test simplu, creez un nou bloc XML și pun textul CSS în interiorul primului nod. În mod normal, nu trebuie să înfășurați CSS pentru CamoPropertySheet în interiorul XML, dar atunci când lucrați cu șiruri mari în interiorul editorului, îmi este mai ușor să folosiți xml deoarece puteți împacheta textul și păstrează unele formatări.
În continuare veți vedea că setăm proprietatea rawCSS la valoarea șirului xml. Aceasta convertește xml într-un șir. Apoi vom crea un nou CamoPropertySheet. În cele din urmă, le spunem foaia de calcul pentru a analiza rawCSS.
Asta e tot ce este pentru a înființa această clasă specială. Configurația este diferită pentru fiecare clasă pe care o testezi. Este important să demonstrați că facem un minim necesar pentru a obține o clasă pregătită pentru a fi testată și nu putem testa o clasă fără valori?
Să mergem direct la asta. Odată ce un CamoPropertySheet a analizat cu succes un șir css, putem solicita o serie de nume de selector pentru a verifica dacă totul a fost într-adevăr analizat. Pentru cei care nu sunt familiarizați cu jargonul CSS, un selector este numele unui stil CSS baseStyle ... ar fi chemat un selector baseStyle.
Aici este ceea ce va arăta testul nostru în limba engleză:
Să ne înlocuim testSampleMethod cu următoarea metodă:
funcția publică funcțiaParseCSS (): void var selectors: Array = sheet.selectorNames; var total: Number = selectors.length; assertEquals (total, 6);
După cum puteți vedea, obținem o serie de nume selector. Apoi vom obține totalul și vom introduce primul nostru test assetEquals. În pasul următor vă voi explica mai bine detaliile aserțiunilor, dar hai să vedem asta și să vedem dacă trece testul.
Când executați testul trebuie să vedeți următoarele în panoul Rezultate FlexUnit:
Bine, testul nostru a trecut. Am primit numărul exact de selectori pe care îi așteptam. Să ne uităm la ce afirmăm testele pe care le putem folosi.
În testarea unităților avem afirmații. Fiecare afirmație se ocupă de un anumit tip de test. Iată o scurtă trecere în revistă a celor mai comune afirmații pe care le veți folosi probabil:
Acum, înainte de a testa un exemplu de fiecare, să ne pregătim dărâma metodă.
Acesta va fi un pas foarte scurt, dar este unul foarte important. Să adăugăm următoarea linie la adresa noastră dărâma dupa metoda super.tearDown ():
foaia = null;
Ceea ce face în realitate este eliminarea referinței la CamoPropertySheet, astfel încât Colectorul de gunoi să îl poată scoate.
Ar trebui să vă configurați întotdeauna dărâma în special atunci când executați mai multe clase de testare sau o suită mare de testare.
Am văzut deja un exemplu de acest lucru înainte de Pasul 7, dar hai să mergem și să adăugăm altul assertEquals. Iată următorul test pe care îl vom efectua:
Pentru a executa testul, să adăugăm următoarea metodă:
funcția publică testToString (): void var compressedCSS: String = "baseStyle x: 10; y: 10; lățime: 100; înălțime: 100; umplutură: 5; margine: 10; baseStyle. : 0; background-color: # 000000; # playButton background-color: #FFFFFF; background-image: url ( '/ images / full_screen_background.jpg'); # fullScreenButton background-color: # FF0000; background- imagine: url ( '/ images / full_screen_background.jpg'); # playButton: peste background-color: # 333333; interactiv cursor: manual; "; assertEquals (foaia.toString (), compressedCSS);
Acum, executați testul unității și asigurați-vă că selectați ambele teste din casetele de selectare. Noile teste nu sunt selectate automat. Dacă totul a mers bine ar trebui să vezi un succes și că au fost executate 2 teste.
Putem face un simplu test pentru a ne asigura că dacă cerem un Selector care nu există, obținem o valoare falsă. Iată cum am face acest lucru cu CamoPropertySheet:
Iată codul pentru efectuarea testului:
Accentsconagua
funcția publică funcția testEmptySelector (): void var selector: PropertySelector = sheet.getSelector ("testSelector"); var există: Boolean = (selector.selectorName == PropertySelector.DEFAULT_SELECTOR_NAME)? fals adevarat; assertFalse (există); După cum puteți vedea, pur și simplu cerem un nume de stil fals testSelector. Verificăm dacă numele selectorului este numele implicit aplicat atunci când nu este găsit niciun selector. În cele din urmă, trecem variabila existentă la assertFalse metodă. Atunci când executați acest lucru ar trebui să vedeți acum 3 treceri care totalizează un succes.
În continuare vrem să ne asigurăm că valoarea textului din CamoPropertySheet nu este niciodată nulă. Să ne uităm la modul de structurare a testului nostru:
Iată metoda noastră de testare:
funcția publică funcția testCSSValue (): void assertNotNull (sheet.toString ());
Acest lucru este destul de drept, așa că atunci când conduceți testul ar trebui să avem acum 5 succese. De fiecare dată când executăm testul, putem verifica numele denumirilor testelor noastre, făcând clic pe folderul Default Suite, panoul cu rezultate FlexUnit, înapoi în Flash Builder.
În acest test următor vom urmări testul gol selector pentru a verifica dacă fiecare selector are o selectorName.
Iată metoda de testare:
testul funcției publiceSelectorHaveNames (): void var selectorA: String = sheet.getSelector ("testSelector") selectorName; var selectorB: String = sheet.getSelector ("baseStyle") selectorName; assertNotUndefined (selectorA, selectorB); Primele două rânduri sunt explicite; noi pur și simplu cerem doi selectori și una dintre care știm că nu există. Când vom face afirmația, totuși veți observa că trecem în două valori în locul celei normale pe care am făcut-o până în acest moment. Acesta nu este un exemplu unic, de fapt, fiecare dintre metodele de afirmație vă permite să treceți în orice număr de valori de testat. Aici, pur și simplu, asigurați-vă că selectorul A și selectorul B nu sunt nedefinite.
Iată un exemplu de comparare strictă a două obiecte. Aici folosesc șiruri de caractere care ar putea să nu fie cea mai bună utilizare a acestui exemplu, dar este bine să vedeți testul în acțiune. Ce vom face?
funcția publică testClone (): void var clone: CamoPropertySheet = sheet.clone () ca CamoPropertySheet; assertStrictlyquali (foaia.toString (), clone.toString ());
După cum puteți vedea, numim metoda de clonare a CamoPropertySheet pentru a obține o copie exactă a PropertySheet. Apoi îl executăm prin testul assert sunând la toString pe fiecare. Dacă testul CSS returnat este același, avem un succes pentru test.
Acum vrem să testați că atunci când cerem un selector, acesta are o proprietate pe care o așteptăm. Iată testul:
Iată metoda de testare:
funcția publică funcția testSelectorHasProperty (): void var selector: PropertySelector = sheet.getSelector ("baseStyle"); assertTrue (selector.hasOwnProperty ( "x")); După cum puteți vedea aici, ne așteptăm pe noi baseStyle selector pentru a avea proprietatea x. Dacă există acest lucru, putem presupune că a fost analizat corect din șirul CSS. Din moment ce există, am trecut acest test.
Fiecare dintre aceste teste devine auto-explicativ cu privire la modul în care le implementați. Să analizăm ce se întâmplă atunci când nu reușim un test în următoarele două etape.
Vom încerca pentru nedefinit acum, dar Flash Camo a fost proiectat să nu se întoarcă undefined. Deci următorul test va eșua. Să verificăm ce vom încerca.
Iată codul pentru test:
funcția publică testClear (): void sheet.clear (); assertUndefined (sheet.toString ());
Acum, să conducem acest test și să mergem la pasul următor pentru a discuta rezultatele.
Dacă ați făcut pasul anterior și ați făcut testul unității, ar trebui să vedeți următoarele în panoul Rezultate FlexUnit:
Observați cum avem 1 eșec din partea noastră testClear metodă?
Dacă faceți dublu clic pe testul eșuat din panoul Rezultate test, veți trece la sursa testului care nu a reușit. Aceasta este o modalitate excelentă de a vă corecta greșeala sau de a modifica testul, astfel încât acesta să nu eșueze. Nu este mult mai mult să nu reușești un test atunci. Fiecare test care nu se va afișa în acest panou, puteți spune panoului să afișeze numai testele eșuate făcând clic pe semnul roșu de exclamare de deasupra în care vă spune câte erori ați avut.
Acum că nu am reușit acest test, înlocuiți-l cu următoarele:
funcția publică testClear (): void sheet.clear (); assertEquals (sheet.toString (), "");
Dacă executați din nou testul, veți vedea că va trece. Acum aveți 7 din 7 teste care au trecut și această clasă funcționează cu succes. Să vorbim despre setarea testelor unității pentru propriile clase personalizate.
Până în acest moment am testat o bibliotecă precompilată, dar ați putea fi interesat de modul în care aceasta va funcționa pe propriile dvs. clase. Vom modifica puțin clasa doc, apoi vom rula un test personalizat pe unitate. Pentru a începe, înlocuiți întregul cod din clasa UnitTestIntro cu următoarele:
pachet import flash.display.Sprite; clasa publica UnitTestIntro extinde Sprite private var _firstName: String; privat var _lastName: String; privat var _loggedIn: Boolean; funcția publică UnitTestIntro () _firstName = "Jesse"; _lastName = "Freeman"; funcția publică get firstName (): String return _firstName; funcția publică obține lastName (): String return _lastName; funcția publică isLoggedIn (): Boolean return _loggedIn;
Odată ce introduceți codul, faceți clic dreapta pe UnitTestIntro și selectați New> Test Case Case. Dacă vă uitați la vrăjitor de data aceasta, veți vedea că toate câmpurile sunt completate pentru noi:
De data aceasta, în loc să faceți clic pe Finalizare, apăsați pe următoarea fereastră:
Aici puteți selecta toate metodele publice din acea clasă pentru a le testa. Observați cum primitorii noștri pentru numele și numele final nu fac parte din această listă. Testarea unităților poate fi efectuată numai pe metode publice. De asemenea, veți vedea fiecare metodă moștenită a clasei, astfel că avem metode Sprite / DisplayObject aici, deoarece clasa noastră doc extinde Sprite. Selectați isLoggedIn și a terminat lovitura.
Dacă parcurgeți în jos până la partea de jos a noii clase de testare care a fost generată, veți vedea că a adăugat automat într-un testMethod pentru isLoggedIn.
Când testați propriul cod Flash Builder vă poate ajuta să automatizați procesul de schemă a testelor. Acesta este un mare ajutor atunci când se ocupă cu clase mari care au o mulțime de metode.
Până acum, ar trebui să aveți o înțelegere solidă a modului în care funcționează unitatea de testare în Flash Builder. Puteți fi chiar gata să începeți să vă configurați propriul test. Există o mulțime de lucruri pe care nu am reușit să le acopere în acest tutorial scurt, așa că aici sunt câteva lucruri pe care să le țineți cont atunci când creați testele dvs..
După cum puteți vedea, configurarea unității de testare este foarte simplă, dar crearea de aplicații care se rotesc în jurul Test Drive Development este o formă de artă în sine. Sperăm că după acest intro va fi confortabil stabilirea unui test simplu pentru a valida faptul că codul funcționează conform așteptărilor. Pe măsură ce vă bazați din ce în ce mai mult pe unitatea de testare, numărul de bug-uri din codul dvs. va scădea dramatic. Atâta timp cât vă amintiți să codificați spre trecerea unui test, păstrarea metodelor mici și validarea testelor dvs. de unitate de multe ori, veți fi bine pe cale de a construi un cod mai stabil.
Vă mulțumim pentru lectură.
