2010-10-14 16 views
23

Actualmente estoy escribiendo una aplicación Java Client Server. Entonces quiero implementar dos bibliotecas, una para el cliente y otra para el servidor. Client Server Communication tiene un protocolo muy estricto, que quiero probar con JUnit.HowTo Unit Client Client Code

Como herramienta de construcción estoy usando Maven y un servidor Husdon para la integración continua.

En realidad, no tengo ninguna buena idea de cómo probar estas bibliotecas cliente/servidor.

me dieron siguientes enfoques:

  1. Sólo tiene que escribir un muñeco de cliente para probar el servidor y escribir un muñeco de servidor para probar el cliente. Desventajas: Lamentablemente, esto dará como resultado muchos trabajos adicionales. No podría estar 100% seguro de que el cliente y el servidor podrían funcionar juntos, porque no estoy seguro de que las pruebas sean completamente idénticas.

  2. Escriba un Proyecto de prueba separado que pruebe el cliente y el servidor juntos.
    Desventajas: Las pruebas de unidad no pertenecen al proyecto en sí, por lo que Hudson no las ejecutará automáticamente. Todos los que cambien algo en una de estas bibliotecas tendrán que ejecutar las pruebas manualmente para asegurarse de que todo sea correcto. Además, no recibiré ningún Informe de cobertura del código.

¿Hay algún método mejor para probar códigos como ese? Tal vez pruebe un proyecto de Maven Multi Module, o algo así.

Espero que alguien haya obtenido una buena solución para ese problema.

Gracias.

Respuesta

2

Así que, finalmente, la resolución era construir un proyecto de varios módulos, con un módulo de prueba independiente que incluye el servidor y el módulo cliente funciona muy bien en husdon. Y aún mejor en el Eclipse IDE. Gracias @ Aaron por la pista

8

Piense en todo el código como "transforma entrada a la salida": X -> [A] -> Y

X son los datos que entra, [A] es el transformador, Y es la salida. En su caso, usted tiene esta configuración:

[Client] -> X -> [Server] -> Y -> [Client] 

Así que las pruebas de la unidad funciona de esta manera:

  1. Usted necesita una prueba que se ejecuta el código de cliente para generar X. Verifique que el código realmente produce X con una afirmación. X debe ser un final static String en el código.

  2. Use la constante X en una segunda prueba para llamar al código del servidor que la transforma en Y (otra constante).

  3. Una tercera prueba se asegura de que el código del cliente puede analizar la entrada Y

De esta manera, se puede mantener las pruebas independientes y aún así asegurarse de que las partes importantes funcionan: La interfaz entre los componentes.

+1

Hmm esta costuras a ser exactamente la forma de implementar una prueba de unidad separada para el servidor y el cliente . De hecho, esto dará como resultado Copiar y pegar las constantes en ambos proyectos, y así implementar un "Dummy Client"/"Dummy Server". Ese es el primer enfoque que enumeré arriba. – StaticBR

+0

¿Por qué pones cliente y servidor en diferentes proyectos? * desconcertado * De todos modos, si realmente quieres hacer eso, entonces crea un proyecto de prueba de tercera unidad que importe los otros dos, por lo que necesitas las constantes solo una vez. –

+2

Hmm dos proyectos, porque el Cliente debe ir a Dispositivos de bajo recurso. Y el Proyecto de prueba es el segundo enfoque que ya enumeré más adelante. Y también escribí las desventajas de este enfoque. – StaticBR

0

Puede usar cualquier marco de objeto simulado para crear objetos simulados - Pruebe jmockit.

1

Mi sugerencia sería utilizar dos niveles de comprobación:

  1. Para su proyecto de cliente/servidor, incluir algunos de burla en las pruebas unitarias para asegurar las interfaces de objetos están funcionando como se esperaba.

  2. Después de la construcción, realice una prueba de integración más extensa, con automatización para instalar el cliente y el servidor compilados en uno o más sistemas de prueba. Luego puede asegurarse de que todos los detalles del protocolo se prueban a fondo. Haga que este proyecto de prueba de integración se active en cada compilación exitosa del proyecto cliente/servidor. Puede usar JUnit para esto y aún así recibir el informe convencional de Hudson.

1

El último enfoque para resolver este problema es mediante el uso de contenedores Docker. Cree un archivo acoplable que contenga una imagen base y todas las dependencias necesarias requeridas para su aplicación de servidor cliente. Cree un contenedor separado para cada tipo de nodo de su sistema cliente-servidor distribuido y pruebe todas las interacciones API/cliente del servidor de punto de entrada usando TestNG o JUnit. La mejor parte de este enfoque es que no se burla de ninguna llamada de servicio. En la mayoría de los casos, puede organizar todas las interacciones de cliente a servidor de extremo a extremo.

Hay un poco de curva de aprendizaje involucrada en este enfoque, pero Docker se está volviendo muy popular en la comunidad Dev especialmente para resolver este problema.

Aquí es un ejemplo de cómo se puede utilizar la API de cliente de ventana acoplable a tirar de imágenes ventana acoplable en su prueba unitaria: https://github.com/influxdb/influxdb-java/blob/master/src/test/java/org/influxdb/InfluxDBTest.java