Share
Il test delle unità è relativamente nuovo per i progetti ActionScript. Sebbene FlexUnit sia in circolazione da un po 'di tempo, non è stato facile configurare e ci sono state molte incongruenze con la documentazione. Fortunatamente per noi, FlexUnit è ora integrato in Flash Builder 4. Anche se la documentazione è ancora scarsa, questo tutorial sarà un buon primer per l'impostazione di una Test Suite, esaminando diversi esempi di test unitari e mostrando come eseguirli / analizzarli.
Per quelli di voi che non hanno familiarità con i test unitari vediamo cosa ha da dire Wikipedia
Nella programmazione per computer, il test unitario è un metodo di verifica e convalida del software in cui il programmatore acquisisce la certezza che le singole unità del codice sorgente sono idonee all'uso ... I test unitari sono generalmente scritti e gestiti dagli sviluppatori di software per garantire che il codice soddisfi il suo design e si comporti come previsto . - wikipedia
In questo tutorial ti mostrerò come ho impostato alcuni semplici test unitari sul mio framework Flash Camo. Dovrai scaricare una copia di Flash Builder 4 (in Beta al momento) per seguirla. Inoltre, ti consigliamo di scaricare l'ultima versione di Flash Camo (2.2.1) da qui.
Creiamo un nuovo progetto chiamato UnitTestIntro.
Dovremo inserire il nostro Flash Camo SWC in a libs / SWCS cartella all'interno del nostro progetto:
Infine, dovremo comunicare al nostro progetto dove trovare il nostro SWC, fare clic con il tasto destro del mouse sul progetto e accedere alle sue proprietà. Vai al percorso di creazione ActionScript e seleziona la scheda Percorso libreria. Fare clic su Aggiungi cartella SWC e puntarlo nella directory lib / swcs.
Ora che abbiamo impostato tutto, possiamo iniziare a fare alcuni test unitari di base. È importante notare che non è possibile eseguire test unitari direttamente in un progetto di libreria Flex. Non è un problema per questo progetto, ma se vuoi testare una libreria di codice quello che faccio di solito è impostare un nuovo progetto (come stiamo facendo qui) quindi collegare i due progetti insieme e creare tutti i test nel nuovo progetto.
Se non stai lavorando in un progetto di Flex Library e vuoi testare il tuo codice, puoi semplicemente creare i tuoi test nello stesso progetto. Suggerirei di tenere separati i due, in questo modo è possibile vedere chiaramente quali sono le classi di test e quali sono le classi reali. Ci arriveremo un po 'più tardi quando vedrai come abbiamo impostato il test.
Prima di iniziare qualsiasi cosa, prendo un momento per capire esattamente cosa farò. Questo è molto critico quando si impostano i test unitari. Questo tipo di sviluppo è chiamato Test Driven Development. Penso di vedere un'altra definizione in arrivo:
Lo sviluppo basato sui test (TDD) è una tecnica di sviluppo software che utilizza brevi iterazioni di sviluppo basate su casi di test pre-scritti che definiscono miglioramenti desiderati o nuove funzioni. Ogni iterazione produce il codice necessario per superare i test di iterazione. Infine, il programmatore o il team rifila il codice per adattarsi alle modifiche. Un concetto chiave di TDD è che preparare i test prima della codifica facilita cambiamenti rapidi di feedback. - wikipedia
Poiché si tratta di una breve introduzione, utilizzeremo una libreria di codice esistente per testarla. Tuttavia, mentre costruisci la tua applicazione, dovresti scrivere dei test per verificare che il codice funzioni e che qualsiasi modifica / refactoring non comprometta l'implementazione del tuo codice. Ecco uno schema dei test che eseguiremo:
Se sei nuovo in Flash Camo puoi controllare l'introduzione che ho scritto (parte 1 e parte 2) ma puoi facilmente fare questo tutorial senza alcuna conoscenza di come funzioni il framework. Ancora una volta, questa sarà semplicemente una libreria di codici con cui testare.
Ora che abbiamo un piano per fare i nostri test, creiamo il nostro primo test. Fare clic con il tasto destro del mouse sul progetto e selezionare Nuovo> Classe caso di test
Verrà ora presentato il wizard di creazione. Dovrebbe essere familiare a chiunque abbia creato una classe in Flex / Flash Builder prima. Ecco come appare la finestra:
Parliamo di alcuni dei nuovi campi nella procedura guidata. Possiamo iniziare con il fatto che Superclass è già compilato per noi: flexunit.framework.TestCase. Non è possibile modificare questo e probabilmente non dovrebbe. Tutto ciò fa estendere la classe di test di base da Unit Test Framework. Poi vedrai alcune caselle di controllo per la generazione del codice. Lasciare tutti questi selezionati per impostazione predefinita. Infine c'è un campo per la classe che vogliamo testare.
Dal momento che stiamo andando a testare CamoPropertySheet di Flash Camo, inseriamo i seguenti valori nel modulo:
Nome: CamoPropertySheetTest Classe da testare: camo.core.property.CamoPropertySheet
Ecco una schermata di come ho impostato questo:
Hit finale e dovremmo avere il nostro primo test pronto per noi per aggiungere del codice a.
Diamo un'occhiata al codice che Flash Builder ha generato per noi:
Iniziamo chiamando una proprietà privata classToTestRef che è impostato sul valore del nostro CamoPropertySheet. Ciò consente al test di creare un'istanza di questa classe e costringe il compilatore a importarlo quando eseguiamo il test.
Il prossimo metodo importante è impostare. Qui è dove creeremo un'istanza della nostra classe di test, la configureremo e ci assicureremo che tutto sia pronto per eseguire un test.
L'ultimo metodo qui è demolire. È qui che distruggeremo l'istanza della nostra classe di test al termine del test. Questo è molto importante quando si eseguono più test.
Potresti aver notato alla fine della lezione c'è un altro metodo chiamato testSampleMethod che è commentato Questo è un esempio di come impostare un singolo test.
Ogni test sarà un metodo che aggiungeremo a questa classe. Quando eseguiamo l'unit test harness chiameremo automaticamente tutti i nostri metodi in modo dinamico, ovviamente iniziando con setUP e finendo con demolire.
Ora che abbiamo una conoscenza di base della configurazione di TestClass, vediamo come eseguirla.
Prima di poterlo eseguire abbiamo bisogno di almeno un test. Let's uncomment the testSampleMethod per questo esempio.
Una volta che hai rimosso il commento testSampleMethod Facciamo clic destro sul nostro progetto e selezionare Esegui come> Esegui FlexUnit Test.
Ora dovresti vedere la seguente finestra che ci chiede di selezionare quale test vogliamo eseguire.
Come vedi, questo è impostato per quando abbiamo un sacco da testare ma per ora abbiamo solo un testSampleMethod da eseguire. Fare clic su Seleziona tutto e premere OK.
Dopo aver eseguito il test, il tuo browser Web comparirà con la seguente pagina:
Se torni a Flash Builder, lo vedrai anche nel pannello Risultati FlexUnit:
Vedi quanto è stato facile correre? Abbiamo eseguito il nostro primo test unitario e abbiamo già un singolo errore. Prima di passare a risolvere questo errore, parliamo di queste due finestre.
La pagina web aperta dovrebbe chiudersi automaticamente ma a volte no. Questo è un semplice swf che esegue i nostri test in Flash e restituisce alcuni dati che il Builder Flash legge per visualizzare i risultati finali del test. È possibile ignorare questa pagina Web per la maggior parte.
Il pannello Risultati FlexUnit è il luogo in cui verranno visualizzati tutti i risultati e un luogo che consente di organizzare e filtrare il feedback del test. Ne parleremo un po 'più avanti nel tutorial quando abbiamo effettivamente qualcosa da testare.
Prima di poter veramente metterci alla prova, dovremo impostare la nostra classe di test. aggiungiamo il seguente codice al impostare metodo:
var xml: XML =; rawCSS = xml.toString (); foglio = new CamoPropertySheet (); sheet.parseCSS (rawCSS);
Avremo anche bisogno di impostare alcune proprietà:
foglio privato var: CamoPropertySheet; private var rawCSS: String;
Ecco cosa sta succedendo in questa configurazione: per poter testare il nostro CamoPropertySheet avremo bisogno di alcuni CSS come stringa. Normalmente vorrei caricare nel CSS da un file esterno, ma dato che stiamo facendo un semplice test, creo un nuovo blocco XML e inserisco il testo CSS all'interno del primo nodo. Normalmente, non è necessario avvolgere i CSS per CamoPropertySheet all'interno di XML, ma quando si lavora con grandi stringhe all'interno dell'editor, trovo più facile usare xml dato che è possibile avvolgere il testo e mantenere una formattazione.
In seguito vedremo che impostiamo la nostra proprietà rawCSS sul valore stringa di xml. Questo converte l'xml in una stringa. Quindi creiamo un nuovo CamoPropertySheet. Infine, diciamo al foglio di analizzare rawCSS.
Questo è tutto quello che devi fare per questa particolare lezione. La configurazione è diversa per ogni classe che si prova. È importante dimostrare che stiamo facendo il minimo indispensabile per ottenere una classe pronta per essere testata e non possiamo testare una classe senza valori possiamo?
Andiamo subito ad esso. Una volta che CamoPropertySheet ha analizzato con successo una stringa css, possiamo richiedere una serie di nomi Selector per verificare che tutto sia stato effettivamente analizzato. Per chi non ha familiarità con il gergo CSS, un selettore è il nome di uno stile css cioè baseStyle ... avrebbe chiamato un selezionatore baseStyle.
Ecco come sarà il nostro test in inglese:
Sostituiamo il nostro testSampleMethod con il seguente metodo:
funzione pubblica testParseCSS (): void var selectors: Array = sheet.selectorNames; var totale: Number = selectors.length; assertEquals (totale, 6);
Come puoi vedere otteniamo una serie di nomi di selettori. Quindi otteniamo il totale e presentiamo il nostro primo test assetEquals. Nel prossimo passaggio spiegherò in dettaglio i metodi assertMethods, ma procediamo e vediamo se il test passa.
Quando esegui il test dovresti vedere quanto segue nel pannello Risultati FlexUnit:
Bello, il nostro test è passato. Abbiamo ricevuto il numero esatto di selettori che ci aspettavamo. Diamo un'occhiata a ciò che asserire test che possiamo usare.
Nei test unitari facciamo delle affermazioni. Ogni asserzione gestisce un particolare tipo di test. Ecco una breve panoramica delle asserzioni più comuni che probabilmente userete:
Ora, prima di testare un esempio di ognuno, impostiamo il nostro demolire metodo.
Questo sarà un passo molto breve ma è molto importante. Aggiungiamo la seguente riga al nostro demolire metodo dopo super.tearDown ():
foglio = null;
Ciò che sostanzialmente fa è rimuovere il riferimento al nostro CamoPropertySheet in modo che il Garbage Collector possa rimuoverlo.
Dovresti sempre impostare il tuo demolire soprattutto quando si eseguono più classi di test o una suite di test di grandi dimensioni.
Abbiamo già visto un esempio di questo prima nel passaggio 7, ma passiamo e aggiungiamo un altro assertEquals. Ecco il prossimo test che eseguiremo:
Per eseguire il test, aggiungiamo il seguente metodo:
funzione pubblica testToString (): void var compressedCSS: String = "baseStyle x: 10; y: 10; width: 100; height: 100; padding: 5; margin: 10; baseStyle .Button x: 0; y : 0; background-color: # 000000; # playButton background-color: #FFFFFF; background-image: url ( '/ images / full_screen_background.jpg'); # FullScreenButton background-color: # FF0000; background- immagine: url ( '/ images / full_screen_background.jpg'); # playButton: oltre background-color: # 333333; interattivo cursore: mano; "; assertEquals (sheet.toString (), compressedCSS);
Ora esegui il test unitario e assicurati di selezionare entrambi i test dalle caselle di controllo. I nuovi test non vengono automaticamente selezionati. Se tutto è andato bene dovresti vedere un successo e che sono stati eseguiti 2 test.
Possiamo fare un semplice test per assicurarci che se richiediamo un Selettore che non esiste otteniamo un valore falso. Ecco come faremmo con il CamoPropertySheet:
Ecco il codice per eseguire il test:
Accentsconagua
public function testEmptySelector (): void var selector: PropertySelector = sheet.getSelector ("testSelector"); var esiste: Boolean = (selector.selectorName == PropertySelector.DEFAULT_SELECTOR_NAME)? falsa verità; assertFalse (disponibile); Come puoi vedere, stiamo semplicemente richiedendo un nome di stile falso testSelector. Controlliamo se il nome del selettore è il nome predefinito applicato quando non viene trovato alcun selettore. Alla fine passiamo la variabile esiste al assertFalse metodo. Quando lo esegui ora dovresti vedere 3 passaggi per un successo.
Successivamente vogliamo essere sicuri che il valore del testo del nostro CamoPropertySheet non sia mai nullo. Diamo un'occhiata a come strutturare il nostro test:
Ecco il nostro metodo di prova:
funzione pubblica testCSSValue (): void assertNotNull (sheet.toString ());
Questo è abbastanza semplice, quindi quando esegui il test dovremmo avere 5 successi. Ogni volta che eseguiamo il test, possiamo verificare i nomi dei nostri test dei metodi facendo clic sulla cartella Suite predefinita sul nostro pannello dei risultati FlexUnit in Flash Builder.
In questo prossimo test seguiremo il test di selezione vuoto per verificare che ogni selettore abbia un selectorName.
Ecco il metodo di prova:
public function testSelectorsHaveNames (): void var selectorA: String = sheet.getSelector ("testSelector"). selectorName; var selectorB: String = sheet.getSelector ("baseStyle"). selectorName; assertNotUndefined (selectorA, selectorB); Le prime due righe sono auto esplicative; chiediamo semplicemente due selettori e uno dei quali sappiamo che non esiste. Tuttavia, quando facciamo l'affermazione, noterai che stiamo passando due valori anziché il normale che abbiamo fatto fino a questo momento. Questo non è un esempio unico, infatti ciascuno dei metodi di assert ti consente di passare un numero qualsiasi di valori da testare. Qui ci assicuriamo semplicemente che il selettore A e il selettore B non siano indefiniti.
Ecco un esempio di come confrontare rigorosamente due oggetti. Qui sto usando stringhe che potrebbero non essere l'uso migliore di questo esempio, ma è bello vedere il test in azione. Cosa faremo?
public function testClone (): void var clone: CamoPropertySheet = sheet.clone () come CamoPropertySheet; assertStrictlyEquals (sheet.toString (), clone.toString ());
Come puoi vedere, chiamiamo il metodo clone di CamoPropertySheet per recuperare una copia esatta del PropertySheet. Quindi lo eseguiamo attraverso il test di asserzione chiamando il accordare metodo su ciascuno. Se il test CSS restituito è lo stesso, abbiamo un successo per il test.
Ora vogliamo testare che quando chiediamo un selettore, ha una proprietà che ci aspettiamo. Ecco il test:
Ecco il metodo di prova:
public function testSelectorHasProperty (): void var selector: PropertySelector = sheet.getSelector ("baseStyle"); assertTrue (selector.hasOwnProperty ( "x")); Come puoi vedere qui ci aspettiamo il nostro baseStyle selettore per avere la proprietà x. Se questo esiste, possiamo presumere che sia stato analizzato correttamente dalla stringa CSS. Dal momento che esiste abbiamo superato questo test.
Ognuno di questi test diventa auto esplicativo su come li implementate. Diamo un'occhiata a cosa succede quando falliamo un test nei prossimi due passaggi.
Stiamo andando a testare per undefined ora, ma Flash Camo è stato progettato per non tornare indefinito. Quindi il seguente test fallirà. Vediamo cosa testeremo per.
Ecco il codice per il test:
public function testClear (): void sheet.clear (); assertUndefined (sheet.toString ());
Ora eseguiamo questo test e passiamo al passaggio successivo per discutere i risultati.
Se hai fatto il passo precedente e hai eseguito il test dell'unità, dovresti vedere quanto segue nel pannello Risultati FlexUnit:
Nota come abbiamo un fallimento dal nostro testClear metodo?
Se fai doppio clic sul test non riuscito nel pannello Risultati test, passerai alla fonte del test che ha avuto esito negativo. Questo è un ottimo modo per correggere il tuo errore o alterare il test in modo che non fallisca. Non c'è molto di più per fallire un test poi questo. Ogni test che fallisce apparirà in questo pannello, puoi dire al pannello di mostrare solo i test falliti facendo clic sul punto esclamativo rosso sopra dove ti dice quanti errori hai avuto.
Ora che abbiamo fallito questo test sostituirlo con il seguente:
public function testClear (): void sheet.clear (); assertEquals (sheet.toString (), "");
Se esegui nuovamente il test, vedrai che passerà. Ora hai 7 test su 7 passati e questa classe sta funzionando con successo. Parliamo dell'impostazione dei test unitari per le tue classi personalizzate.
Fino a questo punto abbiamo testato una libreria precompilata, ma potresti essere interessato a come funzionerà sulle tue classi. Modificheremo un po 'la classe doc, quindi eseguiremo un test unitario personalizzato. Per iniziare, sostituisci tutto il codice nella classe UnitTestIntro con quanto segue:
pacchetto import flash.display.Sprite; public class UnitTestIntro estende Sprite private var _firstName: String; private var _lastName: String; private var _loggedIn: Boolean; public function UnitTestIntro () _firstName = "Jesse"; _lastName = "Freeman"; public function get firstName (): String return _firstName; public function get lastName (): String return _lastName; public function isLoggedIn (): Boolean return _loggedIn;
Una volta ottenuto il codice, fare clic con il tasto destro del mouse UnitTestIntro e selezionare Nuovo> Classe caso di test. Se guardi il wizard questa volta vedrai che tutti i campi sono compilati per noi:
Questa volta, invece di fare clic su Fine, tocca Avanti e guarda la seguente finestra:
Qui puoi selezionare tutti i metodi pubblici di quella classe da testare. Nota come i nostri getter per firstName e lastName non fanno parte di questo elenco. Il test delle unità può essere eseguito solo su metodi pubblici. Inoltre, vedrai tutti i metodi ereditati della classe, quindi abbiamo qui i metodi Sprite / DisplayObject dato che la nostra classe doc estende Sprite. Selezionare isLoggedIn e premi finale.
Se scorri verso il basso fino alla fine della nuova classe di test appena generata, vedrai che è stata aggiunta automaticamente in un testMethod per isLoggedIn.
Durante il test del proprio codice, Flash Builder può aiutare ad automatizzare il processo di scaffolding dei test. Questo è di grande aiuto quando si ha a che fare con classi grandi che hanno molti metodi.
A questo punto dovresti avere una solida conoscenza di come funziona il Test unitario in Flash Builder. Potresti anche essere pronto per iniziare a impostare il tuo test. Ci sono molte cose che non sono riuscito a coprire in questo breve tutorial, quindi ecco alcune cose da tenere a mente quando crei i tuoi test.
Come puoi vedere, l'installazione di Unit Testing è molto semplice, ma la creazione di applicazioni che ruotano attorno a Test Driven Development è una forma d'arte a sé stante. Speriamo che dopo questa introduzione ti sentirai a tuo agio nell'impostare un semplice test per verificare che il tuo codice funzioni come previsto. Man mano che ti affidi sempre di più al test delle unità, il numero di bug nel tuo codice diminuirà drasticamente. Finché ti ricordi di programmare il passaggio di un test, mantenendo i tuoi metodi piccoli e convalidando spesso i tuoi test unitari, sarai sulla buona strada per creare un codice più stabile.
Grazie per aver letto.
