1. El framework de pruebas

El código base tiene pruebas unitarias y de integración que pueden ejecutarse automáticamente para asegurar que el programa funcione como debe. Tales pruebas se escriben a menudo para detonar un error y para asegurar que el error sea detectado si resurge en el futuro, pero también para validar el comportamiento de componentes e interfaces.

Las pruebas se reúnen en el directorio tests/. Las pruebas individuales están en subdirectorios de este directorio. Las pruebas se agrupan en directorios.

2. Ejecutar pruebas

Las pruebas se ejecutan con la secuencia de comandos scripts/runtests generada a partir de scripts/runtests.in durante la construcción. La secuencia de comandos runtests localizará predeterminadamente las pruebas a correr bajo tests/, pero puede ser limitada a correr un conjunto de pruebas especificando el directorio de la(s) prueba(s) como argumento(s).

Un ejemplo corriendo solo las pruebas en tests/lathe/.
$ scripts/runtests tests/lathe/
Running test: tests/lathe
Runtest: 1 tests run, 1 successful, 0 failed + 0 expected, 0 skipped

La secuencia de comandos runtests busca todos los archivos nombrados test, test.sh o test.hal bajo los directorios especificados en la línea de comandos, o bajo tests/ si no se especificó el argumento de línea de comandos. Estos archivos representan las tres maneras de correr las pruebas.

La secuencia de comandos runtests acepta los argumentos siguientes, ver la salida de scripts/runtests -h con la lista oficial:

-n  No elimina archivos temporales de pruebas exitosas.
-s  Detiene la ejecución si alguna prueba falla.
-p  Imprime la salida de error estándar y los archivos de resultado.
-c  Elimina archivos temporales de una ejecución anterior.
-u  Ejecuta sólo las pruebas que requieren acceso de usuario normal.
-v  Muestra las salidas estándar normal y de error (normalmente ocultas).

3. Escribir pruebas

Asegurarse que la prueba pueda correr exitosamente sin una ventana X11 funcional, en otras palabras, sin asignar la variable de ambiente DISPLAY.

  1. Crear un directorio en tests/.

  2. Proporcionar un archivo de secuencia de comandos de prueba.

  3. Evaluar la salida con una de las opciones de abajo.

Estos son los archivos en el directorio considerados para pruebas individuales:

Secuencia de comandos de prueba (solo uno de estos tres)
test

Un programa que es ejecutado y cuyo resultado (código de finalización y salida) son verificados usando los archivos checkresult o expected.

test.sh

Un script bash que se ejecuta y su código finalización y salida se verifican usando checkresult o expected.

test.hal

Un script HAL que se ejecuta usando halrun -f test.hal y su código de finalización y salida son verificados usando checkresult o expected.

Evaluación de la prueba
expected

Un archivo cuyo contenido se compara con la salida de la ejecución de los scripts de prueba. Si la salida de la prueba es idéntica al contenido del archivo expected la prueba es exitosa.

checkresult

Un archivo ejecutable para realizar una validación más compleja que solo comparar la salida del script de prueba. Obtiene el nombre del archivo del programa de prueba por su argumento de línea de comandos. El código de salida del programa controla el resultado de la prueba. Si existe tanto expected como checkresult solo se consulta checkresult para validar la salida de la prueba.

xfail

Si existe este archivo, se espera una falla de prueba y no provoca que runtests devuelva un código de salida señalizando un error.

skip

Si existe este archivo, se omite la prueba y no se ejecuta en absoluto.

control

Este archivo puede ser usado para abanderar necesidades específicas en la prueba. Por el momento, el uso de sudo puede ser abanderado, y se pueden omitir pruebas que requieran sudo al usar runtests -u. Para abanderar tales requerimientos, agregar una línea con Restrictions: sudo a este archivo.

musthave

Este archivo puede contener una lista de prerequisitos de config.h (uno por línea). Si no se cumple, se omitirá la prueba.

  1. ej. si tu prueba depende de que config.h tenga #define HAVE_TK_H 1 y #define HAVE_LIBMODBUS3 yes, agrega una línea con TK_H y una línea con LIBMODBUS3 a este archivo.

4. Algunos enfoques de prueba

Hay varias maneras de estructurar una prueba, dependiendo de lo que se quiere probar. Aquí están algunas ideas de cómo hacerlo.

4.1. "GUI" no interactiva

Si quieres probar algunas operaciones en la interfaz de usuario, un enfoque útil es escribir una "GUI" personalizada simulando las operaciones. Esto puede hacerse creando un configuración normal de LinuxCNC y apuntando el valor de [DISPLAY]DISPLAY a un script que haga las operaciones necesarias para probar el comportamiento.

Se pueden encontrar ejemplos de este enfoque en tests/halui/jogging/ y tests/interp/subroutine-return/.

4.2. Grabando transiciones de pines HAL

Usando los componentes HAL sampler y halsampler uno puede preparar una configuración HAL y recolectar las configuraciones y los cambios a valores de pines y vaciar el resultado en la salida estándar (o un archivo). El resultado final puede compararse con la salida esperada para verificar si HAL se comportó como se esperaba.

Se pueden encontrar ejemplos de este enfoque en tests/multiclick y tests/stepgen.2/.