Marcos de prueba de integración para probar un sistema distribuido?

Question

Tengo un sistema distribuido con componentes repartidos en varias cajas. Hablan entre sí usando tcp o multicast. Cada componente intercambia mensajes entre sí, básicamente son estructuras de datos que se serializan.

¿Qué marcos de prueba de integración tenemos para probar sistemas como estos? Estoy familiarizado con el rubí, así que algo basado en rubíes definitivamente ayudaría.

Answer 1

Supongo que hay diferentes formas de hacerlo. Trato de evitar las pruebas de integración tanto como puedo pero en algún momento es necesario, por supuesto. Esto es solo una sugerencia de lo que haría:

1. El uso de behavior driven approach define claramente los escenarios que desea probar.
2. Do unit testing (No integration), a los procedimientos que representarán las salidas de un módulo.
3. La unidad prueba los procedimientos que se supone que usan entradas de otros módulos, pero usando mocks. Probando la lógica de otro módulo en la corriente.
4. Realice smoke tests, este tipo de prueba asegurará que sus módulos se puedan comunicar entre sí (Este es un tipo de prueba de integración). Creo que la prueba de humo es suficiente prueba de integración. Si lo piensas: ¿por qué el módulo se preocupa por lo que hace otro módulo? (Deja que cada parte haga lo que quiera, pero solo importa cómo comunicarse con ellos)

Personalmente, creo que llamar objetos de un módulo distribuido a otro en los métodos de prueba, no es una buena práctica. Sí, eso sería una prueba de integración, pero creo que es muy fácil de usar.

Siempre tenga en cuenta la pirámide de las pruebas, recuerde que las pruebas de integración y las pruebas de extremo a extremo pueden ser muy costosas. Así que elige sabiamente cuándo usarlos:

que viene del mundo de Java, este siguiente es sólo un poco de información extra que creo que también está relacionado con el tema y puedan ser de su interés:

• El patrón Data Transfer Object, es interesante
• RMI vs EJB vs HTTP (Algunos interesante comentario sobre las diferencias entre las tecnologías de la invocación remota)
• Spock un marco BDD para desarrolladores Java. (Si comprende perfectamente las reglas comerciales, entonces las pruebas son más fáciles)

Espero que lo encuentre útil.

Answer 2

Puede usar STAF/STAX tiene buenas capacidades/servicios para escenarios de pruebas distribuidas como Cliente-Servidor, SAN, etc. También hay un Framework más llamado Twister by Luxoft. Este también es brillante.

Answer 3

Voy a dar mi respuesta para lo que estamos haciendo con un sistema distribuido escrito en Java. Tenemos varios demonios de Linux que realmente son envoltorios de programas Java que se comunican entre sí principalmente a través de una base de datos. Entonces no envían mensajes serializados de ida y vuelta. Usamos dbunit y spring-test para pruebas de integración.Con dbunit, básicamente carga datos, ejecuta su sistema bajo prueba (SUT) y luego verifica que la base de datos se encuentre en el estado correcto. spring-test facilita que las aplicaciones basadas en primavera carguen el contexto de la aplicación mientras se prueban.

Si no tiene una aplicación basada en Java, esto podría no ser tan útil. Las selecciones del marco dependerán en gran medida de las opciones de tecnología y la arquitectura.

Answer 4

Puede finalizar la compra Zopkio: https://github.com/linkedin/Zopkio. Es un marco de código abierto para pruebas funcionales y de rendimiento de sistemas distribuidos.