2011-12-17 8 views
7

Escribí un módulo de máquina de estados finitos para un pequeño juego de fútbol en el que estoy trabajando actualmente. Proporciona una interfaz para configurar un FSM (básicamente sus estados y transiciones). Para cada estado, puede proporcionar funciones que se dispararán en la entrada y la salida, o mientras el FSM permanece en el mismo estado, estas funciones devuelven algunos mensajes. También proporciona una interfaz reactiva (Yampa) que produce el estado variable en el tiempo y recopila los mensajes que se producen con el tiempo. El código está aquí Data/FSM.hs.Haskell: ¿Cómo probar un FSM (reactivo) con quickcheck?

Estoy buscando un buen enfoque para probar este módulo. Como es puro, pensé en darle una oportunidad a quickcheck. No tengo experiencia con Quickcheck, ¡así que cualquier consejo sería apreciado! Mi entendimiento básico hasta ahora: uno proporcionaría algunas funciones que crean FSM de forma más o menos aleatoria y luego ejecuta algunas transiciones (de nuevo más o menos aleatorias) sobre ellas. Pero no puedo ver cómo construir una prueba de esa manera ...

+0

Bueno, ¿qué tipo de pruebas quieres escribir? ¿Qué propiedades o comportamientos necesitan ser verificados? –

+0

Bueno, tal vez el problema es que realmente no sé ... Para algo simple como "para cada fsm válida, cualquier lista finita de transiciones conduce a un estado 'Nada' o al estado 'Just s' donde s es un estado en fsm ", ok. Pero cosas más complicadas como "por cada fsm válida y lista de transiciones y percepciones (variables en el tiempo), cada recopilación de mensajes a lo largo de la ruta de transición debería recogerse", no sabría cómo formalizar esto. Sabría cómo configurar las pruebas unitarias para eso, pero con Quickcheck estoy un poco perdido. – martingw

+0

El enlace está muerto (https://patch-tag.com/r/martingw/Rasenschach/snapshot/current/content/pretty/Data/FSM.hs) y no hay ningún archivo que pueda encontrar – icc97

Respuesta

4

En primer lugar, QuickCheck es posiblemente el más adecuado para la verificación de propiedades amplias y generales. Dando datos arbitrarios de algún tipo, realice algunas operaciones, luego use un predicado para asegurar que el resultado tenga alguna propiedad relativa a la entrada. Las cosas que involucran detalles precisos del comportamiento paso a paso podrían no funcionar tan bien en este estilo, ¡y no deberías sentirte obligado a hacer todo en QuickCheck!

Dicho esto, basado en el ejemplo más complicado que dio en un comentario, ¿ha considerado simplemente generar el resultado esperado junto con el FSM y las entradas? Si puede producir un resultado deseado que sabe que es correcto por construcción, puede ejecutar el FSM en la entrada y comparar el resultado real con la versión construida.

Podría ayudar si evita pensar en las propiedades QuickCheck como probar una función en alguna entrada, sino más bien verificar si uno o más valores satisfacen algún predicado expresado en términos de la función que se está probando. Esta colección de valores (que puede incluir múltiples entradas, salidas, lo que sea necesario) es lo que realmente está siendo generado aleatoriamente por QuickCheck.

+0

Probablemente una mezcla es el mejor enfoque: prueba un resultado específico para una fsm específica y la ingresa con HUnit para situaciones paso a paso, y prueba rápida para propiedades más genéricas. – martingw

+1

@martingw: Creo que una combinación es el mejor enfoque predeterminado, sí. Estoy bastante seguro de que incluso hay cosas en Hackage que proporcionan arneses de prueba unificados para HUnit, QuickCheck y tal vez otras cosas. Probablemente diría que se debe preferir QuickCheck cuando sea posible, pero funciona mejor cuando lo único que se prueba es obtener de A a B, no los detalles de la ruta tomada. –

Cuestiones relacionadas