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:
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.
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.
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
¿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. –
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