Share
Er zijn twee testtypen: 'black box'- en' white box'-stijlen. Black Box testen richt zich op de staat van het object; overwegende dat testen met witte kaders gericht is op gedrag. De twee stijlen vullen elkaar aan en kunnen worden gecombineerd om code grondig te testen. mocking stelt ons in staat gedrag te testen, en deze tutorial combineert het spotconcept met TDD om een voorbeeldklasse te bouwen die verschillende andere componenten gebruikt om zijn doel te bereiken.
Objecten zijn entiteiten die berichten naar elkaar verzenden. Elk object herkent een reeks berichten waarop het op zijn beurt antwoordt. Dit zijn openbaar methoden op een object. Privaat methoden zijn precies het tegenovergestelde. Ze zijn volledig intern voor een object en kunnen niet communiceren met iets buiten het object. Als openbare methoden verwant zijn aan berichten, lijken privémethoden op gedachten.
Het totaal van alle methoden, openbaar en privé, toegankelijk via openbare methoden, vertegenwoordigt het gedrag van een object. Bijvoorbeeld een voorwerp vertellen aan verhuizing oorzaken die niet alleen interageren met de interne methoden, maar ook met andere objecten. Vanuit het oogpunt van de gebruiker heeft het object slechts één eenvoudig gedrag: het moves.
Vanuit het oogpunt van de programmeur moet het object echter een heleboel kleine dingen doen om de beweging te bereiken.
Stel je bijvoorbeeld voor dat ons object een auto is. Om het te doen verhuizing, het moet een draaiende motor hebben, in de eerste versnelling (of omgekeerd) staan en de wielen moeten draaien. Dit is een gedrag dat we moeten testen en waarop we moeten voortbouwen om onze productiecode te ontwerpen en te schrijven.
Onze geteste klasse gebruikt deze dummy-objecten nooit.
Laten we ons voorstellen dat we een programma bouwen om een speelgoedauto op afstand te besturen. Alle commando's naar onze klas komen via de afstandsbediening. We moeten een klasse creëren die begrijpt wat de afstandsbediening verzendt en afgeeft commando's naar de auto.
Dit zal een oefenapplicatie zijn en we nemen aan dat de andere klassen die de verschillende delen van de auto besturen al zijn geschreven. We kennen de exacte handtekening van al deze klassen, maar helaas kon de autofabrikant ons geen prototype sturen - zelfs de broncode niet. Alles wat we weten, zijn de namen van de klassen, de methoden die ze hebben en welk gedrag elke methode omvat. De retourwaarden zijn ook opgegeven.
Hier is het volledige schema van de applicatie. Er is geen uitleg op dit punt; houd het eenvoudig in gedachten voor later gebruik.
Een teststomp is een object om de indirecte invoer van de geteste code te besturen.
Mocking is een teststijl die een eigen set gereedschappen vereist, een reeks speciale objecten die verschillende niveaus van vervalsing van het gedrag van objecten vertegenwoordigen. Dit zijn:
Elk van deze objecten heeft zijn speciale bereik en gedrag. In PHPUnit worden ze gemaakt met de $ This-> getMock () methode. Het verschil is hoe en voor welke redenen de objecten worden gebruikt.
Om deze objecten beter te begrijpen, zal ik de "Toy Car Controller" stap voor stap implementeren met behulp van de soorten objecten, in volgorde, zoals hierboven vermeld. Elk object in de lijst is complexer dan het object ervoor. Dit leidt tot een implementatie die radicaal anders is dan in de echte wereld. Omdat ik een imaginaire applicatie ben, zal ik een aantal scenario's gebruiken die misschien zelfs niet haalbaar zijn in een echte speelgoedauto. Maar goed, laten we ons voorstellen wat we nodig hebben om het grotere geheel te begrijpen.
Dummy-objecten zijn objecten waarvan het System Under Test (SUT) afhankelijk is, maar ze worden nooit gebruikt. Een dummy-object kan een argument zijn dat aan een ander object wordt doorgegeven, of het kan worden geretourneerd door een tweede object en vervolgens worden doorgegeven aan een derde object. Het punt is dat onze geteste klasse deze dummy-objecten nooit echt gebruikt. Tegelijkertijd moet het object op een echt object lijken; anders kan de ontvanger het weigeren.
De beste manier om dit te illustreren is door een scenario voor te stellen; het schema waarvan, is hieronder:
Het oranje object is het RemoteControlTranslator. Het belangrijkste doel is om signalen van de afstandsbediening te ontvangen en deze te vertalen naar berichten voor onze klassen. Op een gegeven moment doet de gebruiker het "Klaar om te gaan" actie op de afstandsbediening. De vertaler ontvangt het bericht en maakt de klassen die nodig zijn om de auto klaar te maken.
De fabrikant zei dat "Klaar om te gaan" betekent dat de motor is gestart, dat de versnellingsbak in neutraal staat en dat de verlichting is ingeschakeld of uitgeschakeld op verzoek van de gebruiker.
Dit betekent dat de gebruiker de status van de lampjes vooraf kan bepalen voordat hij klaar is om te gaan, en dat deze worden in- of uitgeschakeld op basis van deze vooraf gedefinieerde waarde bij activering. RemoteControlTranslator stuurt dan alle nodige informatie naar de CarControl klasse' getReadyToGo ($ engine, $ gearbox, $ electronics, $ lights) methode. Ik weet dat dit allesbehalve een perfect ontwerp is en in strijd is met een paar principes en patronen, maar het is erg goed voor dit voorbeeld.
Start ons project met deze initiële bestandsstructuur:
Onthoud, alle klassen in de CarInterface map wordt geleverd door de fabrikant van de auto; we kennen de implementatie niet. Alles wat we weten zijn de handtekeningen van de klas, maar op dit moment geven we niet om hen.
Ons hoofddoel is om het CarController klasse. Om deze klasse te testen, moeten we ons voorstellen hoe we het willen gebruiken. Met andere woorden, we stellen onszelf in de schoenen van de RemoteControlTranslator en / of enige andere toekomstige klasse die mogelijk wordt gebruikt CarController. Laten we beginnen met het creëren van een case voor onze klas.
class CarControllerTest breidt PHPUnit_Framework_TestCase uit
Voeg vervolgens een testmethode toe.
function testItCanGetReadyTheCar ()
Denk nu na over wat we moeten doorgeven aan de getReadyToGo () methode: een motor, een versnellingsbak, een elektronica-controller en lichtinformatie. Omwille van dit voorbeeld, zullen we alleen de lichten bespotten:
Accentsconagua
require_once '... /CarController.php'; include '... /autoloadCarInterfaces.php'; klasse CarControllerTest breidt PHPUnit_Framework_TestCase uit function testItCanGetReadyTheCar () $ carController = new CarController (); $ engine = new Engine (); $ versnellingsbak = nieuwe versnellingsbak (); $ electornics = new Electronics (); $ dummyLights = $ this-> getMock ('Lights'); $ this-> assertTrue ($ carController-> getReadyToGo ($ engine, $ gearbox, $ electornics, $ dummyLights)); Dit zal uiteraard falen met:
PHP Fatale fout: aanroep op ongedefinieerde methode CarController :: getReadyToGo ()
Ondanks de mislukking gaf deze test ons een startpunt voor onze CarController implementatie. Ik heb een bestand opgenomen, genaamd autoloadCarInterfaces.php, dat stond niet op de oorspronkelijke lijst. Ik besefte dat ik iets nodig had om de lessen te laden, en ik schreef een heel basale oplossing. We kunnen het altijd herschrijven als de echte klassen worden aangeboden, maar dat is een heel ander verhaal. Voor nu houden we vast aan de eenvoudige oplossing:
foreach (scandir (dirname (__ FILE__). '/ CarInterface') als $ bestandsnaam) $ path = dirname (__ FILE__). '/ CarInterface /'. $ Filename; if (is_file ($ path)) require_once $ path;
Ik neem aan dat deze klassenlader voor iedereen duidelijk is; dus laten we de testcode bespreken.
Eerst maken we een instantie van CarController, de klas die we willen testen. Vervolgens maken we instances van alle andere klassen waar we om geven: motor, versnellingsbak en elektronica.
We maken vervolgens een dummy Lichten object door PHPUnit's te bellen getMock () methode en het doorgeven van de naam van de Lichten klasse. Hiermee wordt een instantie van Lichten, maar elke methode komt terug nul--een dummy-object. Dit dummy-object kan niets doen, maar het geeft onze code de interface die nodig is om mee te werken Licht voorwerpen.
Het is heel belangrijk om dat op te merken
$ dummyLightsis eenLichtenobject en elke gebruiker die een verwachtLichtobject kan het dummy-object gebruiken zonder te weten dat het geen echt object isLichtenvoorwerp.
Om verwarring te voorkomen, raad ik aan het type van een parameter te specificeren bij het definiëren van een functie. Dit dwingt de PHP runtime om de argumenten te controleren die aan een functie zijn doorgegeven. Zonder het gegevenstype op te geven, kunt u elk object aan elke parameter doorgeven, wat kan resulteren in het falen van uw code. Met dit in gedachten, laten we de Elektronica klasse:
require_once 'Lights.php'; class Electronics functie turnOn (Lights $ lights)
Laten we een test implementeren:
class CarController function getReadyToGo (Engine $ engine, Gearbox $ versnellingsbak, Electronics $ electronics, Lights $ lights) $ engine-> start (); $ Gearbox-> shift ( 'N'); $ Elektronica-> ZetAan ($ lichten); geef waar terug;
Zoals u kunt zien, de getReadyToGo () functie gebruikte de $ lichten object voor het enige doel van het verzenden naar de $ elektronica voorwerpen aanzetten() methode. Is dit de ideale oplossing voor een dergelijke situatie? Waarschijnlijk niet, maar je kunt duidelijk zien hoe een dummy voorwerp, zonder enige relatie tot de getReadyToGo () functie, wordt doorgegeven aan het ene object dat het echt nodig heeft.
Houd er rekening mee dat alle klassen in de CarInterface map bieden dummy-objecten bij initialisatie. Neem ook aan dat we voor deze oefening verwachten dat de fabrikant in de toekomst de echte klassen levert. We kunnen niet vertrouwen op hun huidige gebrek aan functionaliteit; dus, we moeten ervoor zorgen dat onze tests slagen.
Een teststomp is een object om de indirecte invoer van de geteste code te besturen. Maar wat is indirecte input? Het is een informatiebron die niet direct kan worden gespecificeerd.
Het meest gebruikelijke voorbeeld van een teststrook is wanneer een object een ander object om informatie vraagt en vervolgens iets met die gegevens doet.
Spionnen zijn per definitie meer capabele stubs.
De gegevens kunnen alleen worden verkregen door er een specifiek object voor te vragen, en in veel gevallen worden deze objecten gebruikt voor een specifiek doel binnen de geteste klasse. We willen niet "nieuw" zijn (nieuw SomeClass ()) een klas in een andere klas voor testdoeleinden. Daarom moeten we een instantie van een klasse injecteren die zich gedraagt als SomeClass zonder een echte te injecteren SomeClass voorwerp.
Wat we willen is een stompklasse, die dan leidt afhankelijkheid injectie. Dependency injection (DI) is een techniek die een object injecteert in een ander object, waardoor het wordt gedwongen het geïnjecteerde object te gebruiken. DI is gebruikelijk in TDD en het is absoluut vereist in bijna elk project. Het biedt een eenvoudige manier om een object te dwingen een door de test voorbereide klasse te gebruiken in plaats van een echte klasse die in de productieomgeving wordt gebruikt.
Laten we onze speelgoedauto vooruit laten gaan.
We willen een methode implementeren genaamd moveForward (). Met deze methode wordt eerst een query uitgevoerd StatusPanel object voor de brandstof- en motorstatus. Als de auto klaar is om te vertrekken, geeft de methode de elektronica opdracht om te versnellen.
Om beter te begrijpen hoe een stub werkt, zal ik eerst de code voor de statuscontrole en -versnelling schrijven:
functie goForward (Electronics $ electronics) $ statusPanel = nieuw StatusPanel (); if ($ statusPanel-> engineIsRunning () && $ statusPanel-> thereIsEnoughFuel ()) $ electronics-> accelerate ();
Deze code is vrij eenvoudig, maar we hebben geen echte motor of brandstof om onze te testen ga vooruit() implementatie. Onze code komt niet eens in de als verklaring omdat we geen a hebben StatusPanel klasse. Maar als we doorgaan met de test, ontstaat er een logische oplossing:
function testItCanAccelerate () $ carController = new CarController (); $ electronics = new Electronics (); $ stubStatusPanel = $ this-> getMock ('StatusPanel'); $ StubStatusPanel-> verwacht ($ this-> elke ()) -> methode ( 'thereIsEnoughFuel') -> zal ($ this-> returnValue (TRUE)); $ StubStatusPanel-> verwacht ($ this-> elke ()) -> methode ( 'engineIsRunning') -> zal ($ this-> returnValue (TRUE)); $ carController-> goForward ($ electronics, $ stubStatusPanel); Regel voor regel uitleg:
Ik hou van recursie; het is altijd gemakkelijker om recursie te testen dan lussen.
CarController Elektronica voorwerpStatusPanel thereIsEnoughFuel () nul of meer keren en terugkeren waar engineIsRunning () nul of meer keren en terugkeren waar ga vooruit() met Elektronica en StubbedStatusPanel voorwerpDit is de test die we willen schrijven, maar deze zal niet werken met onze huidige implementatie van ga vooruit(). We moeten het aanpassen:
functie goForward (Electronics $ electronics, StatusPanel $ statusPanel = null) $ statusPanel = $ statusPanel? : nieuw StatusPanel (); if ($ statusPanel-> engineIsRunning () && $ statusPanel-> thereIsEnoughFuel ()) $ electronics-> accelerate ();
Onze modificatie gebruikt afhankelijkheid injectie door een tweede optionele parameter van het type toe te voegen StatusPanel. We bepalen of deze parameter een waarde heeft en een nieuwe maken StatusPanel als $ statusPanel is niets. Dit zorgt ervoor dat een nieuw StatusPanel object wordt gemaakt tijdens de productie, terwijl we toch de methode kunnen testen.
Het is belangrijk om het type van de te specificeren $ statusPanel parameter. Dit zorgt ervoor dat alleen een StatusPanel object (of een object van een geërfde klasse) kan worden doorgegeven aan de methode. Maar zelfs met deze wijziging is onze test nog steeds niet voltooid.
We moeten spot met een testen Elektronica object om ervoor te zorgen dat onze methode vanaf stap 6 oproepen versnellen(). We kunnen de realiteit niet gebruiken Elektronica klasse om verschillende redenen:
Een testspot is een object dat zowel indirecte invoer als uitvoer kan controleren en heeft een mechanisme voor automatische bewering van verwachtingen en resultaten. Deze definitie klinkt misschien een beetje verwarrend, maar het is echt vrij eenvoudig om te implementeren:
function testItCanAccelerate () $ carController = new CarController (); $ electronics = $ this-> getMock ('Electronics'); $ Elektronica-> verwacht ($ this-> eenmaal ()) -> methode ( 'versnellen'); $ stubStatusPanel = $ this-> getMock ('StatusPanel'); $ StubStatusPanel-> verwacht ($ this-> elke ()) -> methode ( 'thereIsEnoughFuel') -> zal ($ this-> returnValue (TRUE)); $ StubStatusPanel-> verwacht ($ this-> elke ()) -> methode ( 'engineIsRunning') -> zal ($ this-> returnValue (TRUE)); $ carController-> goForward ($ electronics, $ stubStatusPanel); We hebben gewoon de $ elektronica variabel. In plaats van een real te maken Elektronica object, we spotten er gewoon een.
Op de volgende regel definiëren we een verwachting op de $ elektronica voorwerp. Om precies te zijn, verwachten we dat het versnellen() methode wordt slechts één keer aangeroepen ($ This-> eenmaal ()). De test gaat nu voorbij!
Voel je vrij om met deze test te spelen. Probeer het te veranderen $ This-> eenmaal () in $ This-> precies (2) en zie wat een leuke foutmelding PHPUnit je geeft:
