Share
Het testen van eenheden is relatief nieuw voor ActionScript-projecten. Hoewel FlexUnit al een tijdje bestaat, was het niet intuïtief in te stellen en er waren veel inconsistenties met de documentatie. Gelukkig voor ons is FlexUnit nu ingebouwd in Flash Builder 4. Hoewel de documentatie nog steeds schaars is, is deze tutorial een goede inleiding voor het opzetten van een testsuite, het doornemen van verschillende unit-testvoorbeelden en laten zien hoe ze moeten worden uitgevoerd / geanalyseerd.
Voor degenen onder u die niet vertrouwd zijn met het testen van eenheden, laten we eens kijken wat Wikipedia te zeggen heeft
Bij computerprogrammering is unit testing een software verificatie- en valideringsmethode waarbij de programmeur er vertrouwen in heeft dat individuele eenheden van broncode geschikt zijn voor gebruik ... Unittests worden meestal geschreven en uitgevoerd door softwareontwikkelaars om ervoor te zorgen dat de code voldoet aan het ontwerp en zich gedraagt zoals bedoeld . - wikipedia
In deze tutorial laat ik je zien hoe ik een paar eenvoudige unit tests heb opgezet op mijn Flash Camo-framework. U moet een kopie van Flash Builder 4 (in Beta nu) downloaden om mee te kunnen doen. U wilt ook de nieuwste versie van Flash Camo (2.2.1) downloaden vanaf hier.
Laten we een nieuw project maken met de naam UnitTestIntro.
We moeten onze Flash Camo SWC in een libs / SWCS map binnen ons project:
Eindelijk moeten we ons project vertellen waar we onze SWC kunnen vinden, klik met de rechtermuisknop op het project en ga in op de eigenschappen ervan. Ga naar het ActionScript-buildpad en selecteer het tabblad Bibliotheekpad. Klik op SWC-map toevoegen en wijs het naar de map lib / swcs.
Nu we alles hebben ingesteld, kunnen we beginnen met het uitvoeren van enkele standaard unit-testen. Het is belangrijk op te merken dat u unittests niet rechtstreeks in een Flex-bibliotheekproject kunt uitvoeren. Dat is geen probleem voor dit project, maar als u een bibliotheek met code wilt testen, is wat ik gewoonlijk doe een nieuw project opgezet (zoals we hier doen), koppel dan de twee projecten samen en maak alle tests in het nieuwe project.
Als u niet in een Flex-bibliotheekproject werkt en uw code wilt testen, kunt u eenvoudig uw tests in hetzelfde project maken. Ik zou willen voorstellen de twee gescheiden te houden, op deze manier kun je duidelijk zien wat testklassen zijn en wat echte klassen zijn. We komen hier later op terug als je ziet hoe we de test hebben opgezet.
Voordat ik iets start, neem ik even de tijd om erachter te komen wat ik precies ga doen. Dit is zeer kritisch bij het instellen van eenheidstests. Dit soort ontwikkeling wordt genoemd Test gedreven ontwikkeling. Ik denk dat ik een andere definitie zie komen:
Testgestuurde ontwikkeling (TDD) is een softwareontwikkelingstechniek die korte ontwikkelingsiteraties gebruikt op basis van vooraf geschreven testcases waarin de gewenste verbeteringen of nieuwe functies worden gedefinieerd. Elke iteratie produceert code die nodig is om de tests van die iteratie te doorstaan. Ten slotte refactoren de programmeur of het team de code om wijzigingen aan te passen. Een belangrijk TDD-concept is dat het voorbereiden van tests vóór het coderen snelle feedbackveranderingen mogelijk maakt. - wikipedia
Omdat dit een korte intro is, gaan we een bestaande codebibliotheek gebruiken om te testen. Als u echter uw eigen toepassing maakt, moet u ondertussen tests schrijven om te valideren dat de code werkt en dat eventuele wijzigingen / correcties de uitvoering van uw code niet schenden. Hier volgt een overzicht van de tests die we zullen uitvoeren:
Als je nog niet bekend bent met Flash Camo, kun je de intro bekijken die ik heb geschreven (deel 1 en deel 2), maar je kunt deze tutorial gemakkelijk doen zonder enige kennis van hoe het framework werkt. Nogmaals, dit wordt gewoon een codebibliotheek voor ons om mee te testen.
Nu we een plan hebben om onze testen uit te voeren, laten we onze eerste test maken. Klik met de rechtermuisknop op uw project en selecteer Nieuw> Case testen
Je krijgt nu de creatie wizard te zien. Het moet vertrouwd zijn voor iedereen die al eerder een klasse heeft gemaakt in Flex / Flash Builder. Dit is hoe het venster eruit ziet:
Laten we het hebben over enkele nieuwe velden in de wizard. We kunnen beginnen met het feit dat Superclass al voor ons is ingevuld: flexunit.framework.TestCase. Je kunt dit niet veranderen en waarschijnlijk ook niet. Dit alles doet de basistestklasse uitbreiden vanuit het Unit Test Framework. Vervolgens ziet u enkele selectievakjes voor het genereren van codes. Laat deze allemaal standaard aangevinkt. Eindelijk is er een veld voor de klas die we willen testen.
Aangezien we Flash Camo's CamoPropertySheet gaan testen, vullen we de volgende waarden in het formulier:
Naam: CamoPropertySheetTest Klasse om te testen: camo.core.property.CamoPropertySheet
Hier is een schermafbeelding van hoe ik dit heb ingesteld:
Klik op Finish en we zouden onze eerste test klaar moeten hebben om er wat code aan toe te voegen.
Laten we eens kijken naar de code die Flash Builder voor ons heeft gegenereerd:
We beginnen met het hebben van een privé-eigenschap genaamd classToTestRef welke is ingesteld op de waarde van onze CamoPropertySheet. Hierdoor kan de test een instantie van deze klasse maken en wordt de compiler gedwongen om deze te importeren wanneer we onze test uitvoeren.
De volgende belangrijke methode is opstelling. Hier zullen we een exemplaar van onze testklasse maken, het configureren en ervoor zorgen dat alles gereed is om een test uit te voeren.
De laatste methode is hier scheuren. Dit is waar we onze testklasse-instantie zullen vernietigen wanneer de test is voltooid. Dit is erg belangrijk bij het uitvoeren van meerdere tests.
Je hebt misschien gemerkt aan het einde van de les dat er een andere methode is genoemd testSampleMethod die is becommentarieerd. Dit is een voorbeeld van hoe u een enkele test zou instellen.
Elke test zal een methode zijn die we aan deze klasse toevoegen. Wanneer we de eenheidstestharnas uitvoeren, worden al onze methoden automatisch dynamisch aangeroepen, uiteraard beginnend met setUP en afwerking met scheuren.
Nu we een basiskennis van de TestClass-installatie hebben, laten we kijken hoe we het kunnen uitvoeren.
Voordat we dit kunnen uitvoeren, hebben we minimaal één test nodig. Laten we commentaar geven op de testSampleMethod voor dit voorbeeld.
Zodra u het commentaar hebt geannuleerd testSampleMethod laten we met de rechtermuisknop op ons project klikken en Uitvoeren als> FlexUnit-test uitvoeren.
U zou nu het volgende venster moeten zien waarin u wordt gevraagd om te selecteren welke test we willen uitvoeren.
Zoals je ziet, is dit ingesteld voor wanneer we veel moeten testen, maar voor nu hebben we maar één testSampleMethod om uit te voeren. Klik op Alles selecteren en druk op OK.
Nadat de test is uitgevoerd, verschijnt uw webbrowser met de volgende pagina:
Als u teruggaat naar Flash Builder, ziet u dit ook in het deelvenster FlexUnit-resultaten:
Zie je hoe gemakkelijk dit was om te rennen? We hebben onze eerste unit-test uitgevoerd en we hebben al een enkele fout. Voordat we verdergaan om deze fout te verhelpen, laten we het hebben over deze twee vensters.
De webpagina die geopend was, moet automatisch worden gesloten, maar soms niet. Dit is een eenvoudige swf die onze tests in FLash uitvoert en een aantal gegevens uitgeeft die de Flash Builder voor de uiteindelijke resultaten van de test weergeeft. U kunt deze webpagina grotendeels negeren.
In het deelvenster FlexUnit-resultaten worden alle resultaten weergegeven, evenals een plaats waar u de testfeedback kunt organiseren en filteren. We zullen dit iets later in de tutorial bespreken als we iets hebben om te testen.
Voordat we echt kunnen testen, moeten we onze testklasse instellen. laten we de volgende code toevoegen aan de opstelling methode:
var xml: XML =; rawCSS = xml.toString (); sheet = nieuwe CamoPropertySheet (); sheet.parseCSS (rawCSS);
We moeten ook een aantal eigenschappen instellen:
privévariablad: CamoPropertySheet; private var rawCSS: String;
Dit is wat er gebeurt in deze opstelling: om ons CamoPropertySheet te testen, hebben we CSS nodig als een tekenreeks. Normaal zou ik de CSS vanuit een extern bestand laden, maar omdat we een eenvoudige test doen, maak ik gewoon een nieuw XML-blok en plaats ik de CSS-tekst in het eerste knooppunt. Normaal gesproken hoef je geen CSS in te voegen voor de CamoPropertySheet in XML, maar bij het werken met grote reeksen in de editor vind ik het gemakkelijker om xml te gebruiken, omdat je de tekst kunt inpakken en er nog wat opmaak is.
Vervolgens zie je dat we onze rawCSS-eigenschap instellen op de tekenreekswaarde van de xml. Dit zet de xml om in een string. Vervolgens maken we een nieuw CamoPropertySheet. Ten slotte vertellen we het blad om de rawCSS te ontleden.
Dat is alles wat er is om deze specifieke klasse op te zetten. De setup is anders voor elke klasse die je test. Het is belangrijk om aan te tonen dat we het absolute minimum doen om een klasse klaar te maken om getest te worden en we kunnen een klasse niet testen zonder waarden kunnen we?
Laten we erop toezien. Zodra een CamoPropertySheet een css-string met succes heeft geparseerd, kunnen we een array met selectornamen aanvragen om te controleren of alles inderdaad is geparseerd. Voor degenen die niet bekend zijn met CSS-jargon, is een selector de naam van een CSS-stijl, dwz baseStyle ... zou een selector hebben genoemd baseStyle.
Hierin ziet onze test er in het Engels uit:
Laten we onze vervangen testSampleMethod met de volgende methode:
public function testParseCSS (): void var selectors: Array = sheet.selectorNames; var total: Number = selectors.length; assertEquals (totaal 6);
Zoals je ziet, krijgen we een reeks selectornamen. Vervolgens krijgen we het totaal en introduceren we onze eerste test assetEquals. In de volgende stap zal ik de assertMethods in meer detail uitleggen, maar laten we dit gewoon uitvoeren en kijken of de test slaagt.
Wanneer u de test uitvoert, ziet u het volgende in het deelvenster FlexUnit-resultaten:
Mooi, onze test is geslaagd. We ontvingen het exacte aantal selectors dat we verwachtten. Laten we eens kijken naar welke assert-tests we kunnen gebruiken.
Bij het testen van eenheden voeren wij beweringen uit. Elke bewering handelt een bepaald type test af. Hier is een kort overzicht van de meest voorkomende beweringen die u waarschijnlijk zult gebruiken:
Laten we, voordat we een voorbeeld van elk testen, onze scheuren methode.
Dit gaat een heel korte stap zijn, maar het is een heel belangrijke stap. Laten we de volgende regel toevoegen aan onze scheuren methode na super.tearDown ():
blad = null;
Wat dit in feite doet is de verwijzing naar onze CamoPropertySheet verwijderen zodat de Garbage Collector het kan verwijderen.
Je moet altijd je scheuren vooral bij het uitvoeren van meerdere testklassen of een grote testsuite.
We hebben hier al eerder een voorbeeld van gezien in stap 7, maar laten we doorgaan en er nog een toevoegen assertEquals. Dit is de volgende test die we zullen uitvoeren:
Laten we de volgende methode toevoegen om de test uit te voeren:
openbare functie testToString (): void var gecomprimeerdCSS: 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; achtergrond- image: url ( '/ images / full_screen_background.jpg'); # playButton: meer dan background-color: # 333333; interactieve cursor: hand; "; assertEquals (sheet.toString (), gecomprimeerde CSS);
Voer nu de eenheidscontrole uit en zorg ervoor dat u beide tests uit de selectievakjes selecteert. Nieuwe tests worden niet automatisch geselecteerd. Als alles goed is gegaan, zou je een succes moeten zien en dat 2 tests zijn uitgevoerd.
We kunnen een eenvoudige test doen om zeker te zijn dat als we een Selector aanvragen die niet bestaat, we een valse waarde krijgen. Dit is hoe we dit zouden doen met de CamoPropertySheet:
Hier is de code om de test uit te voeren:
Accentsconagua
public function testEmptySelector (): void var selector: PropertySelector = sheet.getSelector ("testSelector"); var exists: Boolean = (selector.selectorName == PropertySelector.DEFAULT_SELECTOR_NAME)? false: true; assertFalse (bestaan); Zoals u kunt zien, vragen we eenvoudig om een nepstijlnaam testSelector. We controleren of de naam van de selector de standaardnaam is die wordt toegepast wanneer er geen selector wordt gevonden. Als laatste geven we de variabelen bestaande door aan de assertFalse methode. Wanneer u dit uitvoert, ziet u nu drie passen die een succes zijn.
Vervolgens willen we ervoor zorgen dat de tekstwaarde van onze CamoPropertySheet nooit nul is. Laten we eens kijken naar hoe onze test te structureren:
Dit is onze testmethode:
public function testCSSValue (): void assertNotNull (sheet.toString ());
Dit is vrij eenvoudig, dus als je de test uitvoert, zouden we nu 5 successen moeten behalen. Telkens wanneer we de test uitvoeren, kunnen we controleren of de namen van onze methodetests te zien zijn door in ons standaardvenster FlexOnit Results in de map Standaardsuite te klikken in Flash Builder.
In deze volgende test gaan we verder met de lege selectietest om te controleren of elke selector een heeft selectorName.
Hier is de testmethode:
public function testSelectorsHaveNames (): void var selectorA: String = sheet.getSelector ("testSelector"). selectorName; var selectorB: String = sheet.getSelector ("baseStyle"). selectorName; assertNotUndefined (selectorA, selectorB); De eerste twee regels spreken voor zichzelf; we vragen gewoon om twee selectors en waarvan we weten dat die niet bestaat. Wanneer we de bewering doen, zul je echter merken dat we twee waarden doorgeven in plaats van de normale waarden die we tot nu toe hebben bereikt. Dit is geen uniek voorbeeld, in feite kunt u met elk van de assert-methoden een willekeurig aantal waarden doorgeven om te testen. Hier zorgen we er eenvoudig voor dat selectorA en selectorB niet ongedefinieerd zijn.
Hier is een voorbeeld van hoe je twee objecten strikt kunt vergelijken. Hier gebruik ik tekenreeksen die misschien niet het beste gebruik van dit voorbeeld zijn, maar het is goed om de test in actie te zien. Wat gaan we doen?
public function testClone (): void var clone: CamoPropertySheet = sheet.clone () als CamoPropertySheet; assertStrictlyEquals (sheet.toString (), clone.toString ());
Zoals je ziet, noemen we de kloonmethode van de CamoPropertySheet om een exacte kopie van het PropertySheet terug te krijgen. Vervolgens voeren we de assert-test uit door de toString methode op elk. Als de geretourneerde CSS-test hetzelfde is, hebben we een succes voor de test.
Nu willen we testen dat wanneer we een selector aanvragen, deze een eigenschap heeft die we verwachten. Hier is de test:
Hier is de testmethode:
public function testSelectorHasProperty (): void var selector: PropertySelector = sheet.getSelector ("baseStyle"); assertTrue (selector.hasOwnProperty ( "x")); Zoals je hier kunt zien, verwachten we onze baseStyle selector om de x-eigenschap te hebben. Als dit bestaat, kunnen we aannemen dat het correct is geparseerd uit de CSS-reeks. Aangezien het bestaat, zijn we geslaagd voor deze test.
Elk van deze tests verklaart voor zichzelf hoe u ze implementeert. Laten we eens kijken wat er gebeurt als we een test in de volgende twee stappen niet halen.
We gaan nu testen op undefined, maar Flash Camo is ontworpen om niet-gedefinieerd terug te sturen. Dus de volgende test mislukt. Laten we eens kijken waar we voor gaan testen.
Hier is de code voor de test:
public function testClear (): void sheet.clear (); assertUndefined (sheet.toString ());
Laten we nu deze test uitvoeren en naar de volgende stap gaan om de resultaten te bespreken.
Als u de vorige stap hebt uitgevoerd en de unit-test hebt uitgevoerd, ziet u het volgende in het deelvenster FlexUnit-resultaten:
Merk op hoe we 1 fout hebben van onze testClear methode?
Als u dubbelklikt op de mislukte test in het deelvenster Testresultaten, gaat u naar de bron van de test die is mislukt. Dit is een geweldige manier om uw fout te corrigeren of de test aan te passen, zodat deze niet faalt. Er is niet veel meer aan het falen van een test dan dit. Elke test die mislukt zal verschijnen in dit paneel, je kunt het paneel vertellen om alleen mislukte tests te tonen door op het rode uitroepteken hierboven te klikken, waar het je vertelt hoeveel fouten je had.
Nu we deze test hebben afgewezen, vervang je deze door het volgende:
public function testClear (): void sheet.clear (); assertEquals (sheet.toString (), "");
Als u de test opnieuw uitvoert, ziet u dat deze doorgaat. Nu heb je 7 van de 7 goedgekeurde tests en deze klas werkt met succes. Laten we het hebben over het instellen van eenheidstests voor uw eigen aangepaste klassen.
Tot nu toe hebben we een voorgecompileerde bibliotheek getest, maar misschien ben je wel geïnteresseerd in hoe dit in je eigen lessen zal werken. We gaan de doc-klasse een beetje aanpassen en voeren er een aangepaste unit-test op uit. Om te beginnen, vervangt u alle code in de klasse UnitTestIntro door het volgende:
pakket import flash.display.Sprite; public class UnitTestIntro breidt Sprite uit 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;
Zodra u de code hebt ingevoerd, klikt u met de rechtermuisknop op UnitTestIntro en selecteer Nieuw> Testcaseklasse. Als je deze keer naar de wizard kijkt, zie je dat alle velden voor ons zijn ingevuld:
Deze keer klik je in plaats van op Voltooien op Volgende en kijk je naar het volgende venster:
Hier kunt u alle openbare methoden van die klasse selecteren om te testen. Merk op dat onze getters voor firstName en lastName geen deel uitmaken van deze lijst. Het testen van eenheden kan alleen op openbare methoden worden uitgevoerd. Ook zul je elke overgenomen methode van de klasse zien, dus we hebben hier Sprite / DisplayObject-methoden omdat onze docklasse Sprite uitbreidt. kiezen isLoggedIn en druk op finish.
Als u naar beneden scrolt naar de onderkant van de nieuwe testklasse die zojuist is gegenereerd, ziet u dat deze automatisch is toegevoegd in een testMethod voor isLoggedIn.
Bij het testen van uw eigen code kan Flash Builder het proces van het steigerwerk van uw tests helpen automatiseren. Dit is een grote hulp bij het omgaan met grote klassen met veel methoden.
Inmiddels zou u een goed begrip moeten hebben van hoe Unit Testing in Flash Builder werkt. U bent misschien zelfs klaar om te beginnen met het opzetten van uw eigen test. Er zijn een heleboel dingen die ik niet in deze korte tutorial kon bespreken, dus hier zijn enkele dingen om in gedachten te houden bij het maken van je tests.
Zoals je kunt zien, is het opzetten van Unit Testing heel eenvoudig, maar het creëren van applicaties die draaien om Test Driven Development is een kunst op zich. Hopelijk kan je na deze intro een eenvoudige test opzetten om te valideren dat je code werkt zoals verwacht. Naarmate u meer en meer vertrouwt op het testen van eenheden, zal het aantal fouten in uw code drastisch verminderen. Zolang u eraan denkt om te coderen voor het behalen van een test, uw methoden klein te houden en uw unittests vaak te valideren, bent u goed op weg om stabielere code te bouwen.
Bedankt voor het lezen.
