¿Cómo puedo crear una simulación SerialPort usando la biblioteca Moq?

Question

Tengo que escribir mucho código relacionado con los puertos serie. Por lo general, habrá un dispositivo conectado en el otro extremo del cable y generalmente creo mis propios simulacros para simular su comportamiento.

Estoy empezando a consultar Moq para ayudar con mis pruebas unitarias. Es bastante simple de usar cuando solo se necesita un stub, pero quiero saber si es posible y, en caso afirmativo, cómo creo un simulacro para un dispositivo de hardware que responde de manera diferente según lo que quiero probar.

Un ejemplo simple:

Uno de los dispositivos de E interfaz con recibe un comando (mover a la posición x), da de nuevo un mensaje de ACK y pasa a un estado "movimiento" hasta que alcanza la posición ordenada.

Quiero crear una prueba donde envíe el comando mover y luego seguir consultando el estado hasta que llegue a la posición final.

Quiero crear dos versiones del simulacro para dos pruebas diferentes, una donde espero que el dispositivo llegue a la posición final con éxito y la otra donde fallará.

¿Demasiado pedir?

Answer 1

Si tiene una interfaz para un objeto de puerto serie en su programa, entonces Moq puede hacerlo creando un objeto de puerto en serie simulado (Moq es bueno para los resquicios y los simulacros de cualquier complejidad).

Si desea intercepción las llamadas a la clase SerialPort BCL antes de que alcancen el hardware (sin tener que crear una interfaz de puerto serie y la aplicación, además de una aplicación de prueba), entonces se necesita algo más potente. Eso es lo que Moles es para.

Si realmente quiere emular un dispositivo, esto va más allá de "pruebas unitarias". En este nivel, es posible usar com0com para agregar un par de puertos seriales virtuales y escribir un emulador para su dispositivo con el que puedan hablar sus pruebas. En este nivel, es mucho más complejo (aunque no imposible) automatizar las pruebas.

Answer 2

Si usa TDD con simulaciones, debe dejar que sus pruebas definan sus objetos. ya parece que tienes un diseño en mente antes de haber escrito alguna prueba.

Su diseño preliminar tiene:

• Comando remitente
• receptor Comando
• sondeo (síncrono/asíncrono)
• Como corolario que debe tener una función

Timeout Eso es ya las responsabilidades que su SerialController debe implementar. Wow eso es mucho para implementar sin ninguna prueba en su lugar.

Comience bien y fácil.

Pruebe y pruebe con la idea de 'Último momento responsable'.

¿Qué pasa con la sintaxis que va a utilizar?

Es posible que desee comprobar esto: how-to-test-reliability-of-my-own-small-embedded-operating-system

me dan enlaces a modo de objeto Atómica de hacer hardware y James Greening Blog. James tiene algunos buenos documentos sobre cómo hacer TDD con hardware (no importa las cosas de ruby, c y C++. Si estás haciendo hardware, entonces has jugado con c y C++ antes;)).

Por cierto, parece bastante emocionante lo que estás haciendo.