Software bouwen is een complex proces. Naast het beheersen van de verschillende tools en programmeertalen, is er ook het begrijpen van verschillende software-ontwikkeling rollen. Zoals de meesten van ons weten, gaat het bij grote projecten niet alleen om codering. Bij grote projecten zijn ook andere middelen betrokken voor het verzamelen van eisen, prototyping en testen.
Het proces van het valideren van code wordt vaak aangeduid als Quality Assurance. Deze uitdrukking is echter enigszins misleidend. In plaats van de kwaliteit van de code te verzekeren, is het echte doel de kwaliteit te meten – vaak tijdens de ontwikkeling van het project. Dit subtiele verschil, ook bekend als testgestuurde ontwikkeling (bv. TDD), kan worden gezien wanneer de kwaliteitsfuncties worden bekeken. Deze omvatten het volgende:
WAAROM UNIT TESTS?
Zoals blijkt, wordt kwaliteitsmeting vaak gegroepeerd in geautomatiseerde en handmatige activiteiten. Als iemand die geïnteresseerd is in algoritmen, werkt aanvullende code die bekend staat als unit tests om uw primaire softwareproject te testen. Unit tests worden meestal geschreven door ontwikkelaars en zijn de focus in een TDD omgeving. Bijvoorbeeld, unit tests zijn essentieel bij de ontwikkeling van dit boek. Laten we met behulp van het iOS XCTest Framework eens bekijken hoe unit tests werken in Swift.
WERKEN MET XCTEST
Als je bekend bent geraakt met de Swift-concepten die in het boek de revue zijn gepasseerd, zou het leren schrijven van unit tests rechttoe rechtaan moeten zijn. Zoals besproken, unit tests werken om code te oefenen die geen eind-gebruiker interface heeft. Ter illustratie, laten we eens kijken naar testgevallen die een Stack datastructuur oefenen.
Hoewel het boek niet ingaat op de bijzonderheden van de Xcode Integrated Development Environment (IDE), moet worden opgemerkt dat tests kunnen worden uitgevoerd per functie, klasse of doel. Met Xcode worden unit tests opgezet door een nieuwe Test Target toe te voegen aan uw primaire code project. Eenmaal geconfigureerd, kunnen unit tests worden uitgevoerd vanuit de IDE of command line.
TEST REGELS
Hoewel het niet verplicht is, wordt het als best practice beschouwd als het unit test bestand nauw overeenkomt met de naamgeving conventie van onze implementatie bestand(en). In ons geval zullen we StackTest.swift gebruiken. Om toegang te krijgen tot de primaire Stack methoden en eigenschappen van ons hoofdproject, zal het bestand ook een testbare import verklaring bevatten:
Net als andere unit test frameworks, werkt XCTest door Swift taal functies te integreren met specifieke test-gerelateerde functies. De essentiële methoden zijn gegroepeerd als asserties. Bij het maken van tests, zal de compiler unit tests herkennen met functies voorafgegaan door het test keyword.
In tegenstelling tot reguliere Swift functies, zijn unit tests opzettelijk ontworpen als op zichzelf staande eenheden van logica. Als gevolg daarvan, accepteren test methods geen argumenten en geven geen waarden terug. Als alternatief kunnen testgegevens worden beheerd door middel van helper-methoden en initialisatie / afbreken sequenties. Beschouw het volgende:
TEST PLANNING
Zoals besproken, is de belangrijkste operatie van een Stack datastructuur het toevoegen en verwijderen van items. In plaats van een enkele functie te schrijven om alle bewerkingen te testen, isoleert ons testplan elke belangrijke Stack-bewerking met zijn eigen test. Zoals te zien is bij testPushStack, controleert de assertie XCTAssertTrue de correcte initialisatie van de Stack.count variabele. De volgende stap is het oefenen van Stack.push door het itereren door de array van numberList items. Om te verifiëren dat elke test dezelfde data gebruikt, wordt numberList gevuld met de setup-methode van de XCTestCase klasse.
Met de unit-test voor het toevoegen van Stack-items geïmplementeerd, kunnen we de volgende test schrijven voor het verwijderen van items: