Estoy desarrollando un pequeño servidor TCP, que procesará algunos paquetes TCP y se comportará de manera diferente en función de la solicitud.¿Cómo se prueba un servidor TCP? ¿Vale la pena?
¿Cómo puedo escribir la prueba de unidad para esto? Si es realmente difícil de escribir, ¿vale la pena el esfuerzo?
Lo primero que debe hacer es separar el comportamiento (s) de los paquetes TCP que son entrantes. Resúmalo en una mesa de despacho u otra cosa similar.
A continuación, escriba pruebas de unidad para cada uno de los comportamientos independientemente de cómo se invocaron. Puede probar la capa final de comportamiento TCP -> con una herramienta de prueba que escriba o tome prestada. Esa capa debería ser casi trivial si el código se considera adecuadamente.
Valdrá la pena.
El número de pruebas unitarias debe coincidir con el tipo de solicitudes (comportamientos diferentes). Esto será útil cuando realice modificaciones y vea si impactó o no en otras partes del servidor TCP.
Puede imitar el envío de paquetes TCP con varias herramientas disponibles. Déjame saber como va.
No sé nada de .net, pero puedo contarte sobre las pruebas unitarias.
Tienes que factorizar las cosas. Por ejemplo, su servidor puede ejecutarse en un hilo y hacer algún trabajo. Donde hace el trabajo debe estar dentro de una función. Probablemente también tenga un objeto de solicitud. Haga que la "función de trabajo" del servidor tcp tome el objeto de solicitud como parámetro. Luego, realice la prueba unitaria como de costumbre: al comienzo de la prueba, configure la solicitud y páselo a la "función de trabajo" del objeto del servidor tcp. En realidad, no tiene los enchufes abiertos del servidor ni nada. Solo está probando las unidades de los métodos que hacen el trabajo, y solo probando el manejo de la solicitud. Usted es no conectores de prueba o confiabilidad de red o algo por el estilo. Necesitas probar eso de otra manera.
Puede echar un vistazo a NMock, una biblioteca burlona para .NET. Si dos partes están involucradas en una prueba unitaria, siempre es bueno simplemente "burlarse" de una de las partes (la que no está probando, en ese caso, el Cliente).
Sin embargo, esto requerirá algunos cambios en su código, pero créanme, vale la pena.
Intentaré extraer el bit específico de TCP del bit de procesamiento. ¿Su protocolo realmente es basado en paquetes, o está basado en flujo? Si se basa en secuencias, puede hacer que la parte de procesamiento acepte una transmisión (o posiblemente un par de secuencias, una para entrada y otra para salida) y alimentarla con MemoryStream o su propia implementación de secuencia similar que le da un poco más de control.
De cualquier forma, básicamente quieres burlar el lado de la red para que puedas probar la lógica real sin tener que involucrar a la red en absoluto. Probando la capa de red (es decir, la parte delgada de la lógica entre las clases de red de la infraestructura y la lógica de procesamiento) puede ser un poco más difícil, pero si puedes hacerlo lo suficientemente delgado no debería haber mucho para probar.
Buen punto, debe abstraer tanto el análisis sintáctico del paquete, como la lógica y poner las pruebas unitarias en ambos. El uso de una interfaz para la lógica comercial y luego una biblioteca burlona le permite aislar el código de análisis sintáctico. –
No puedo darte ningún ayudante específico ya que tu pregunta es bastante abierta.
Sin embargo, parece que le gustaría escribir un servidor/cliente falso según sus necesidades. Valdría la pena mirar Rhino Mocks.
Es posible que también desee echar un vistazo a NMemCached project de Oren que implementa un servidor de caché mediante una implementación personalizada de TCP/IP. Ese proyecto tiene algunas pruebas de unidad/integración interesantes escritas usando Rhino Mocks.
Sin duda vale la pena el esfuerzo. Lo que he dominado para una aplicación basada en servidor pequeño HTTP = en la que estoy trabajando es tener una serie de scripts que inician solicitudes en el servidor usando wget. Luego usé diff para comparar el resultado wget guardado con lo que esperaba obtener, e informar cualquier referencia. Ejecuto este conjunto de scripts cada vez que cambio el servidor, y ha captado muchos errores.
Obviamente, esto solo funciona para los servidores HTTP, pero valdrá la pena escribir una pequeña aplicación que pueda activar las solicitudes TCP en su servidor y guardar los resultados.
Si escribe un servidor TCP, también debe escribir una biblioteca de cliente. A menos que esté haciendo algo elegante, simplemente puede disparar paquetes sobre el adaptador de bucle invertido entre la prueba de su unidad y el servidor stub. Solo necesita verificar que está haciendo TCP correctamente con estas pruebas, ya que el resto de sus pruebas deberían, en la forma de prueba de la unidad adecuada, anular/omitir la lógica TCP/socket y saltar directamente a la unidad individual que se está probando.
Hacer todo esto vale la pena. Si eres lo suficientemente nuevo como para TCP y no estás seguro de cómo y por qué debes probarlo en una unidad, es probable que cometas algunos errores/suposiciones erróneas sobre cómo escribir tu código TCP, y las pruebas unitarias serán invaluables para las llamadas. que fuera. También encontrará que lo alienta a concentrarse más en las necesidades del cliente, lo que tiende a generar un protocolo más limpio y una base de código de servidor más limpia.
+1: La biblioteca del cliente probada con el servidor simulado es un esfuerzo. El servidor real se puede probar a través de la biblioteca del cliente. Así es como estamos haciendo este tipo de cosas. –
¿Qué herramienta me recomiendan? Estoy planeando obtener una licencia para TypeMock, pero no estoy muy seguro de si es compatible. –
Tiene que usar algunas otras herramientas para este propósito, como http://www.netscantools.com/nstpro_packet_generator_tcp.html –