Stap 13: Tester software
Als u een RAMBo board echter niet gebruikt, moet u zich aan te passen de software aan uw Raad van bestuur. De software werd onlangs herschreven van kras om een eenvoudig poort in de andere boards. Basiskennis van Python programmeren is wel vereist.
Het nieuwe ontwerp zorgt voor een meer modulaire aanpak waar elke proef wordt vertegenwoordigd door een uniek object en elk testtype wordt uitgevoerd in de eigen klas. Een paar basisklassen zijn beschikbaar om te zorgen voor de basisfunctionaliteit van de testgevallen, vastleggen mechanisme en testen van de logica.
De tests / module bevat basisklassen en testen modules. De basisklassen zijn:
- Proefproces: Dit is de basisklasse voor een test-case geïmplementeerd om te testen van een specifieke functie
- TestContext: Dit is de basisklasse voor de context gegeven aan de proeven terwijl ze worden uitgevoerd
- TestRunner: Dit is de basisklasse voor de runner-klasse die de testverzameling elke test wordt uitgevoerd.
Er zijn een paar algemene tests, zoals de TestGPIO in gpio.py en TestAnalog analog.py die zelf hebben meer specifieke testen klassen die zijn afgeleid van hen zoals TestMosfets en TestEndstops die zijn afgeleid van TestGPIO en TestThermistors, TestVRefs en TestSupplyRails die uit TestAnalog voortvloeien. Er zijn ook enkele specifieke tests zoals de ProgramFirmware , die een test-wrapper voor avrdude is en TestMotors zal testen stappenmotoren en controleer of dat ze werken allemaal goed.
Ter uitvoering van een nieuwe test, moet u afgeleid van de klasse van de TestCase en negeren de methoden _test en _verify . De _test methode moet uitvoeren van de test met wat is beschikbaar in het context-object (meer daarover later) terwijl de methode _verify moet zelf de 'self.status' naar een waarde in de TestStatus enum.
De context-object dat wordt doorgegeven aan de methoden _test en _verify is een object dat is afgeleid van TestContext, het doel ervan is om rond de informatie tussen de tests die kunnen worden gebruikt door de testcases. Bijvoorbeeld, is de interface voor toegang tot de DUT is beschikbaar in context.target , terwijl de controller beschikbaar als context.controller is. Ook de meeste tests zal zijn vereist toegang aan specifieke velden van het object context.pinmapping.
U moet een klasse ontlenen aan TestContext om de vereiste informatie verstrekken aan test cases. Meest in het bijzonder in de afgeleide klasse moet u een self.pinmapping -object instantiëren. Wilt u stroom aan/uit de voeding aan voordat en nadat een test uitgevoerd bijvoorbeeld, kunt u het doen door het overschrijven van de methoden TestingStarted en TestingEnded .
Ten slotte moet u een nieuwe klasse voor uw Raad van bestuur die is afgeleid van TestRunnerimplementeren. Dit men is eenvoudig, dat u hoeft enkel een self.tests -variabele met een lijst van proefproces objecten definiëren en terug te keren van de context die u hebt gemaakt via de eigenschap context .
U kunt vervolgens uw TestRunner -object maken en roep de methode Run om alle tests uitvoeren, of kun je het een lijst van specifieke tests uit te voeren als u dat wenst.
Er is veel meer dat kan worden gezegd over de software, zoals dodelijke, verplichte, _finally, test gevallen, of het configureren van de logging systeem als een database wilt gebruiken, of hoe om de samenvatting van de uitvoering van de proeven te krijgen, of om te schakelen van specifieke tests, wat elke test status betekent, enz... Echter de broncode is vrij eenvoudig en goed gedocumenteerd en je kunt een heleboel dingen ontdekken door het lezen van de code.
Ik laat u met een mockup voor een potentiële GUI voor de test software waarin de GUI kan dynamisch worden gegenereerd vanuit een willekeurig exemplaar van de TestRunner en die geeft controle van elke proef aan de gebruiker.
