Paso 13: Software de Comprobador
Si no usas un tablero de RAMBo sin embargo, necesita adaptar el software a su Junta Directiva. El software fue recientemente reescrito desde cero para permitir que un puerto fácil en otras tablas. Conocimientos básicos de programación de Python es necesaria sin embargo.
El nuevo diseño permite un enfoque más modular, donde cada prueba está representado por un objeto único y cada tipo de prueba se aplica en su propia clase. Unas clases base están disponibles para atender la funcionalidad básica de los casos de prueba, mecanismo de registro y la prueba lógica.
Las pruebas de módulo contiene las clases base y módulos de prueba. Las clases base son:
- TestCase: Esta es la clase base para un caso de prueba para una característica específica de la prueba
- TestContext: Esta es la clase base para el contexto dado a las pruebas mientras que se están ejecutando
- TestRunner: Esta es la clase base de la clase de corredor que se ejecutará cada prueba en la serie de pruebas.
Hay unas pruebas genéricas, como el TestGPIO en gpio.py y TestAnalog analog.py que a su vez tiene más específico probar las clases que se derivan de ellos como TestMosfets y TestEndstops que se derivan de TestGPIO y TestThermistors, TestVRefs y TestSupplyRails que se derivan de TestAnalog. Hay también algunas pruebas específicas como la ProgramFirmware que es un contenedor de prueba para avrdude y TestMotors que probar motores paso a paso y comprobar que todo funcionan correctamente.
Para implementar una nueva prueba, debe derivar de la clase TestCase y reemplazar los métodos _test y _verify . El método de _test necesita ejecutar la prueba con lo que está disponible en el objeto de contexto (más sobre esto más adelante) mientras que el método _verify establecer el 'self.status' a un valor en la enumeración de TestStatus .
El contexto que se pasa a los métodos _test y _verify es un objeto que deriva de TestContext, su propósito es pasar alrededor de información entre las pruebas que pueden ser utilizadas por los casos de prueba. Por ejemplo, la interfaz para acceder a la DUT está disponible en context.target mientras el controlador está disponible como context.controller. Además, mayoría de las pruebas requerirá acceso a campos específicos de la context.pinmappingdel objeto.
Usted tendrá que derivar una clase TestContext para proporcionar la información necesaria para los casos de prueba. Más específicamente, en la clase derivada, debe crear una instancia de un objeto self.pinmapping . Si usted necesita para encendido y apagado la alimentación antes y después de un examen por ejemplo, puede hacerlo reemplazando los métodos TestingStarted y TestingEnded .
Por último, sería necesario implementar una nueva clase de la tarjeta que se deriva de TestRunner. Este es simple, que basta definir una variable self.tests que contiene una lista de objetos TestCase y devolver el contexto creado a través de la propiedad de contexto .
Entonces puede crear el objeto TestRunner y llamar al método Run para ejecutar todas las pruebas, o puede dar una lista de pruebas específicas para ejecutar si lo desea.
Hay mucho más que puede decirse sobre el software, como fatal, necesario, _finally casos de prueba, o cómo configurar el sistema de registro para utilizar una base de datos o cómo obtener el Resumen de la ejecución de pruebas, o para desactivar las pruebas específicas, que cada estado medios de prueba, etc... Sin embargo, el código fuente es bastante sencillo y está bien documentado y puede descubrir un montón de cosas por leer el código.
Me voy con una maqueta de un GUI potencial para el software de prueba en la que la GUI puede ser generada dinámicamente desde cualquier instancia de TestRunner y que da un control de cada prueba para el usuario.
