Desarrollo de máquinas de estado con desarrollo basado en pruebas

Dado que los modelos de máquina de estado se utilizan ampliamente en sistemas integrados, este artículo explora varias estrategias para desarrollar software de máquina de estado (SM) bajo el enfoque de desarrollo basado en pruebas (TDD). Esta publicación comienza explicando los conceptos básicos de la máquina de estados y la técnica TDD. Finalmente, presenta métodos simples y ordenados para desarrollar software de máquina de estado escrito en C usando el enfoque TDD.

Un modelo SM se compone de estados, transiciones y acciones. Mientras que un estado es una condición de un sistema o un elemento, una transición es una ruta de un estado a otro, generalmente iniciada por un evento de interés que conecta un estado predecesor (fuente) con un estado posterior (objetivo). Los comportamientos reales ejecutados por el elemento se representan en acciones.

En la máquina de estado de UML, las acciones pueden estar asociadas con la entrada a un estado, la salida de un estado, una transición per se o lo que se llama una "transición interna" o "reacción". Todos los formalismos de la máquina de estado (incluidas las máquinas de estado UML) asumen universalmente que una máquina de estado completa el procesamiento de cada evento antes de que pueda comenzar a procesar el siguiente. Este modelo de ejecución se llama Run To Completion (RTC). En este modelo, las acciones pueden llevar tiempo, pero cualquier evento pendiente debe esperar hasta que se complete la máquina de estado, incluida la acción de salida completa, la acción de transición y la secuencia de la acción de entrada en ese orden.

Antes de abordar las estrategias para desarrollar máquinas de estados mediante TDD, conviene mencionar su definición, importancia y aplicación.

En primer lugar, TDD es una técnica para crear software de forma incremental. En pocas palabras, no se escribe ningún código de producción sin antes escribir una prueba unitaria fallida. Las pruebas son pequeñas. Las pruebas están automatizadas. La conducción de pruebas es lógica, es decir, en lugar de sumergirse en el código de producción (dejando las pruebas para más adelante), el practicante de TDD expresa el comportamiento deseado del código en una prueba. Una vez que la prueba falla, el practicante de TDD escribe el código, haciendo que la prueba pase. En el núcleo del proceso TDD, hay un ciclo repetido compuesto de pasos cortos conocidos como "microciclos TDD".

Los pasos del ciclo TDD en la siguiente lista se basan en el libro "Desarrollo basado en pruebas para C integrado" de James Grenning:

• Agregue una pequeña prueba.
• Ejecute todas las pruebas y si la nueva falla, es posible que ni siquiera se compile.
• Realice los pequeños cambios necesarios para aprobar la prueba.
• Ejecute todas las pruebas y compruebe si pasa la nueva.
• Refactorice para eliminar la duplicación y mejorar la expresividad.

Usemos el diagrama de la Figura 1 para encontrar una forma más sencilla de desarrollar una máquina de estados usando TDD. Cuando se inicializa la máquina de estado, comienza desde el StateA Expresar. Una vez que recibe el Alfa evento, la máquina de estado cambia al StateB estado ejecutando las acciones xStateA (), effect () y nStateB () en ese orden. Entonces, ¿cómo se puede probar el SM de la Figura 1 para determinar si se comporta apropiadamente?

Figura 1. Máquina de estado básica (Fuente:VortexMakes)

La forma más tradicional y sencilla de probar un SM como la Figura 1 consiste principalmente en verificar la tabla de transición de estado del SMUT (State Machine Under Test). Esto hace que un caso de prueba por estado , en el que el SMUT es estimulado por los eventos de interés para verificar qué transiciones se desencadenan. Al mismo tiempo, esto implicará verificar el estado objetivo y las acciones ejecutadas para cada transición disparada. Si una acción es lo suficientemente compleja, es más adecuado realizar un caso de prueba específico para eso. (El artículo Prueba de máquinas de estado usando prueba unitaria explica esta estrategia en profundidad).

Cada caso de prueba se divide en cuatro fases distintas según los patrones de xUnit:

• Configuración establece las condiciones previas de la prueba, como el estado actual del SM ( StateA ), el evento que se procesará ( Alfa ) y los resultados esperados de la prueba, que son el estado de destino de la transición ( StateB ) y la lista ordenada de acciones a ejecutar (xStateA (), effect () y nStateB ()).
• Ejercicio estimula la máquina de estado con el Alpha evento.
• Verificar comprueba los resultados obtenidos.
• Limpieza devuelve la máquina de estado bajo prueba a su estado inicial después de la prueba. Es opcional.

La estrategia mencionada anteriormente es suficiente para desarrollar un SM usando TDD. Sin embargo, en algunos casos se necesita más de una transición para verificar la funcionalidad. Esto se debe a que el efecto solo se hace visible debido a una cadena de acciones de transiciones posteriores, lo que significa que la funcionalidad involucra un conjunto de estados, eventos y transiciones del SMUT. En estos casos, es más apropiado probar un escenario completo y funcional que las transiciones de estado aisladas. Como resultado, los casos de prueba son más funcionales y menos abstractos que las estrategias mencionadas anteriormente.

Usemos la máquina de estados de la Figura 2 para explorar este concepto.

Figura 2. La máquina de estado DoWhile (Fuente:VortexMakes)

La Figura 2 muestra una máquina de estado llamada DoWhile, que modela un ciclo de ejecución similar al "do-while". DoWhile se dibujó con la herramienta Yakindu Statechart Tool. Las acciones "x =0" y "salida =0" se llaman cuando se crea DoWhile y estas acciones establecen el valor predeterminado de todos los atributos de DoWhile. ¿El número de iteraciones de bucle debe establecerse mediante "x ++" o "x =(x> 0)? x–:acciones x '. La acción "i =0" establece las condiciones iniciales para el bucle. El cuerpo del bucle se ejecuta mediante la acción "i ++", que mantiene las iteraciones del bucle, luego la condición de terminación es evaluada por el pseudoestado de elección a través de la protección "i ==x". Si es cierto, el cuerpo del bucle se evalúa de nuevo y así sucesivamente. Cuando la condición de terminación se vuelve falsa, el ciclo termina ejecutando la acción "salida =i".

Es útil crear una lista de prueba antes de desarrollar una nueva funcionalidad. La lista de pruebas se deriva de la especificación y define la mejor visión de lo que se debe hacer. Dado que no necesita ser perfecto, la lista anterior es solo un documento temporal que podría modificarse más adelante. La lista de prueba inicial para DoWhile se muestra a continuación:

• Todos los datos se establecen de forma predeterminada después de que se inicializa SM
• Incrementar el atributo X
• Disminuir el atributo X
• Se puede ejecutar un solo ciclo de iteración
• Se puede ejecutar un ciclo de iteración múltiple
• Se puede ejecutar un ciclo sin iteración
• Compruebe los valores fuera de los límites

Para desarrollar la máquina de estado DoWhile, Ceedling y Unity se utilizarán junto con la técnica de programación más simple pero lúcida:el uso de oraciones "switch-case". Ceedling es un sistema de compilación para generar un entorno completo de prueba y compilación para un proyecto C; Unity es un arnés de prueba de lenguaje C expresivo portátil y liviano para proyectos en C.

Dos archivos representan esta máquina de estado, DoWhile.hy DoWhile.c, por lo que son el código fuente bajo prueba. El Listado de Código 1 muestra un fragmento del archivo test_DoWhile.c, que implementa la lista de pruebas anterior aplicando la estrategia mencionada anteriormente. Para mantener este artículo simple, el Listado de Código 1 solo muestra el caso de prueba:"Se puede ejecutar un solo ciclo de iteración", que es implementado por test_SingleIteration (). Tanto el código como el modelo están disponibles en el repositorio https://github.com/leanfrancucci/sm-tdd.git.

Listado de código 1:Prueba de iteración única (Fuente:VortexMakes)

Esta prueba verifica que DoWhile puede ejecutar solo una iteración correctamente. Para hacer eso, test_SingleIteration () inicializa la máquina de estado DoWhile llamando a DoWhile_init () (línea 96). Establece el número de iteración para que el bucle DoWhile ejecute cero. Después de eso, DoWhile está listo para procesar eventos llamando a DoWhile_dispatch (). Para ejecutar una sola iteración, test_SingleIteration () envía el Up evento a DoWhile (línea 97). Este evento incrementa el número de iteración a uno. La prueba inicia el ciclo enviando el Inicio evento (línea 98), luego envía el Alfa evento para que DoWhile ejecute una sola iteración (línea 99). Esto se verifica verificando que el valor del atributo out sea igual al número de iteraciones ejecutadas (línea 101). Finalmente, DoWhile debe permanecer en StateC estado (línea 102).

Para demostrar que DoWhile puede ejecutar más de una iteración, test_SingleIteration () se extiende como se muestra en el Listado de Código 2.

Listado de código 2:Prueba de iteración múltiple (Fuente:VortexMakes)

La prueba test_NoneIteration () que se muestra en el Listado de código 3 verifica que DoWhile no ejecuta ninguna iteración al recibir un Alpha evento sin establecer previamente el número de iteración a través de Up eventos.

Listado de código 3:prueba sin iteración (fuente:VortexMakes)

Aunque los detalles de implementación de DoWhile no son el objetivo de este artículo, el Listado de Código 4 y el Listado de Código 5 muestran parte de los archivos DoWhile.cy DoWhile.h. Estos archivos en realidad representan una implementación demostrativa de DoWhile usando oraciones "cambiar mayúsculas y minúsculas" en C.

Listado de código 4:Fragmento de la implementación de DoWhile (Fuente:VortexMakes)

Listado de código 5:Fragmento de la especificación DoWhile (Fuente:VortexMakes)

Ambas estrategias presentadas anteriormente proporcionan métodos simples y ordenados para desarrollar software de máquina de estado utilizando TDD, uno de los enfoques más importantes para aumentar la calidad del software.

La primera estrategia consiste principalmente en verificar la tabla de transición de estado del SMUT. Este método crea un caso de prueba por estado . La otra estrategia propone realizar un caso de prueba para un escenario completo y funcional , que frecuentemente involucra un conjunto de estados, eventos y acciones del SMUT. Esta segunda estrategia hace que la prueba sea más funcional y menos abstracta que la primera. Aunque estas estrategias son independientes de un tipo particular de sistema, lenguaje de programación o herramienta, son muy útiles en sistemas embebidos, porque muchas de ellas tienen un comportamiento basado en estados que normalmente se define en una o más máquinas de estados.

Se eligió el lenguaje C porque es uno de los lenguajes más populares para el desarrollo de software integrado. Entonces, para aplicar TDD en ese idioma, se eligieron Ceedling y Unity. Para concluir, estos métodos definitivamente permiten a los desarrolladores construir de una manera más simple y ordenada un software mucho más flexible, fácil de mantener y reutilizable que los enfoques tradicionales.