LinuxCNC Documentation

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  do not remove temporary files for successful tests.
-s  stop after any failed test.
-p  print stderr and result files.
-c  Remove temporary files from an earlier test run.
-v  Show stdout and stderr (normally it's hidden).
-d  Enable crash dumps: print a gdb backtrace of the core when a test crashes.

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.

skip

If this file exists and is not executable, the test is skipped and not executed at all. If it is executable, it is run first and the test is skipped when it exits non-zero. Tests never use sudo: a test that builds or installs a component with halcompile needs the build tree, so its skip file is [ -z "$SYSTEM_BUILD" ], which skips it when testing installed packages.

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/.