Pruebas

Esta sección describe brevemente las opciones disponibles en spring-test para aplicaciones Spring MVC.

• Simulacros de API de Servlet: implementaciones simuladas de contratos de API de Servlet para controladores de pruebas unitarias, filtros y otros componentes web.

• TestContext Framework: soporte para cargar la configuración de Spring en pruebas JUnit y TestNG, incluido el almacenamiento en caché eficiente de la configuración cargada en métodos de prueba y soporte para cargar WebApplicationContext con MockServletContext.

• Prueba de Spring MVC: un marco, también conocido como MockMvc, diseñado para probar controladores anotados a través de DispatcherServlet (es decir, con reconocimiento de anotaciones), incluido con el marco Spring MVC. pero sin servidor HTTP.

• REST del lado del cliente: spring-test proporciona un MockRestServiceServer que se puede utilizar como servidor simulado para probar el código del lado del cliente que utiliza internamente RestTemplate.

• WebTestClient: Creado para probar aplicaciones WebFlux, pero también se puede utilizar para pruebas de integración de un extremo a otro en cualquier servidor a través de una conexión HTTP. Es un cliente reactivo y sin bloqueo que es muy adecuado para realizar pruebas en escenarios asincrónicos y de transmisión.

Protocolo WebSocket

Esta parte de la documentación de referencia cubre la compatibilidad con la pila de servlets, la mensajería WebSocket, incluidas las interacciones sin formato de WebSocket, la emulación de WebSocket a través de SockJS y la mensajería de publicación y suscripción a través de STOMP como un subprotocolo además de WebSocket.

Introducción al protocolo WebSocket

El protocolo WebSocket, RFC 6455, proporciona una forma estandarizada de establecer una conexión full-duplex de dos Canal de comunicación bidireccional entre un cliente y un servidor a través de una conexión TCP. Este es un protocolo TCP diferente a HTTP, pero está diseñado para ejecutarse sobre HTTP, utiliza los puertos 80 y 443 y le permite reutilizar las reglas de firewall existentes.

La comunicación WebSocket comienza con una solicitud HTTP que utiliza el encabezado HTTP Upgrade para actualizar o, en este caso, migrar al protocolo WebSocket. El siguiente ejemplo muestra esta interacción:

GET /spring-websocket-portfolio/portfolio HTTP/1.1
Host: localhost:8080
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: Uc9l9TMkWGbHFD2qnFHltg==
Sec-WebSocket-Protocol: v10.stomp, v11.stomp
Sec-WebSocket-Version: 13
Origin: http://localhost:8080

1. Encabezado Upgrade.
2. Usando la conexión Upgrade.

En lugar del código de estado habitual 200, el servidor habilitado para WebSocket emite un mensaje similar al siguiente:

HTTP/1.1 101 Switching Protocols 
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: 1qVdfYHU9hPOl4JYYNXF623Gzn0=
Sec-WebSocket-Protocol: v10.stomp

1. Cambio de protocolo

Después de un protocolo de enlace exitoso, el socket TCP subyacente a la solicitud de actualización HTTP permanece abierto para que el cliente y el servidor puedan continuar enviando y recibiendo mensajes.

Una introducción completa al protocolo WebSocket está fuera del alcance de este documento. Consulte "RFC 6455", el capítulo sobre WebSockets en HTML5, o cualquiera de las muchas descripciones y tutoriales que hay en Internet.

Tenga en cuenta que si el servidor WebSocket se ejecuta detrás de un servidor web (como nginx), probablemente será necesario configurarlo para pasar solicitudes de actualización de WebSocket al servidor. Del mismo modo, si su aplicación se ejecuta en un entorno de nube, consulte las instrucciones de su proveedor de nube con respecto a la compatibilidad con WebSocket.

HTTP frente a WebSocket

Aunque el protocolo WebSocket está diseñado para ser compatible con HTTP y originarse a partir de una solicitud HTTP, es importante comprender que los dos protocolos implican arquitecturas y modelos de programación de aplicaciones completamente diferentes.

En HTTP y REST, una aplicación se modela como un conjunto de URL. Para interactuar con la aplicación, los clientes acceden a estas URL en un estilo de solicitud-respuesta. Los servidores enrutan las solicitudes al controlador apropiado según la URL, el método y los encabezados HTTP.

Por el contrario, los WebSockets suelen utilizar sólo una URL para la conexión inicial. Posteriormente, todos los mensajes de la aplicación se transmiten a través de la misma conexión TCP. Esto apunta a una arquitectura de mensajería asincrónica basada en eventos completamente diferente.

WebSocket también es un protocolo de transporte de bajo nivel que, a diferencia de HTTP, no impone ninguna semántica al contenido del mensaje. Esto significa que no hay forma de enrutar o procesar el mensaje hasta que la semántica del mensaje sea acordada entre el cliente y el servidor.

Los clientes y servidores de un WebSocket pueden negociar el uso de un protocolo de mensajería de nivel superior (como STOMP) utilizando el encabezado Sec-WebSocket-Protocol en la solicitud de protocolo de enlace HTTP. En ausencia de esto, deben llegar a sus propios acuerdos.

¿Cuándo debería utilizar WebSockets?

El protocolo WebSockets puede hacer que una página web sea dinámica e interactiva. Sin embargo, en muchos casos, una combinación de Ajax y un flujo HTTP o un sondeo de formato largo puede ser una solución sencilla y eficaz.

Por ejemplo, las noticias, el correo y las redes sociales deben actualizarse dinámicamente, pero es bastante aceptable hacerlo cada pocos minutos. Por otro lado, las aplicaciones de colaboración, los juegos y las aplicaciones financieras deben ejecutarse en tiempo real con más frecuencia.

El retraso en sí no es un factor decisivo. Si el volumen de mensajes es relativamente pequeño (por ejemplo, al monitorear fallas de la red), la transmisión por secuencias o el sondeo a través del protocolo HTTP pueden ser una solución efectiva. Es la combinación de baja latencia, alta frecuencia y alto volumen el mejor argumento a favor del uso de WebSocket.

Recuerde también que en Internet, los proxies restrictivos que están fuera de su control pueden impedir las comunicaciones WebSocket, ya sea porque no están configurados para enviar el encabezado Upgrade o porque cierran conexiones de larga duración, lo que parecen estar inactivos. Esto significa que usar WebSocket para aplicaciones internas dentro de un firewall es una solución más sencilla que para aplicaciones públicas.