질문에 대한 답변

질문의 역사

WebSocket 테스트는 간단한 HTTP 요청-응답 모델에서 지속적인 연결 검증으로 발전했습니다. 초기 자동화는 소켓을 상태 있는 스트림 의미를 무시하고 블랙 박스 HTTP 업그레이드로 취급했습니다. 현대의 실시간 애플리케이션은 프레임을 통한 이진 프로토콜 Protobuf와 같은 순서 보장 검증 및 TCP 저하에 대한 복원력을 요구합니다. 이 질문은 테스트가 메시지 소비의 경합 조건으로 인해 간헐적으로 실패하는 불안정한 CI 파이프라인을 관찰하면서 발생했습니다. 팀들은 본질적으로 비동기적이며 푸시 기반 아키텍처와 결정론적 주장을 조화시키는데 어려움을 겪었습니다.

문제

핵심 도전 과제는 비결정적 대기를 도입하지 않고 시간적 속성(순서, 대기 시간)을 검증하는 데 있습니다. WebSocket 연결은 병렬 테스트 실행과 충돌하는 상태 비저장 세션을 유지하여 포트 충돌 및 공유 구독 오염을 초래합니다. 이진 페이로드는 JSON 주장과 다르게 스키마 인식 역직렬화를 요구하여 검증 로직이 복잡해집니다. 네트워크 복원력 테스트는 애플리케이션 코드를 수정하지 않고 전송 계층에서 결함 주입을 요구합니다. 전통적인 폴링 기반 Selenium 또는 REST Assured 패턴은 요청-응답 주기를 가정하므로 서버 푸시 스트림에는 실패합니다.

해결책

Project Reactor 또는 RxJava를 사용하여 메시지 스트림을 관찰 가능한 시퀀스로 모델링하는 반응형 테스트 하네스를 설계합니다. 각 테스트를 전용 Docker 네트워크 네임스페이스에 격리하면서 Toxiproxy를 사용하는 TestContainers를 배포하여 네트워크 파편화 및 대기 시간을 시뮬레이션합니다. 각 테스트가 고유한 세션 식별자를 생성하는 상관관계 UUID 전략을 구현하여 병렬 작업자 간 메시지 라우팅 격리를 보장합니다. 이진 검증을 위해 Protobuf 스키마에 대해 역직렬화한 후 주장을 수행하는 ByteBuf 매처 또는 사용자 정의 Hamcrest 매처를 사용합니다. 신호 수 및 순서에 대한 명시적 기대를 가지고 StepVerifier를 사용하여 테스트를 실행합니다.

@Testcontainers
public class WebSocketResilienceTest {
    
    @Container
    private static final ToxiproxyContainer toxiproxy = new ToxiproxyContainer("ghcr.io/shopify/toxiproxy:2.5.0");
    
    private WebSocketClient client;
    private ToxiproxyClient proxyClient;
    
    @BeforeEach
    void setUp() {
        client = new ReactorNettyWebSocketClient();
        proxyClient = new ToxiproxyClient(toxiproxy.getHost(), toxiproxy.getControlPort());
    }
    
    @Test
    void shouldMaintainMessageOrderingUnderNetworkLatency() throws IOException {
        Proxy proxy = proxyClient.createProxy("ws", "0.0.0.0:8666", "host.testcontainers.internal:8080");
        proxy.toxics().latency("latency", ToxicDirection.DOWNSTREAM, 2000);
        
        StepVerifier.create(
            client.execute(
                URI.create("ws://" + toxiproxy.getHost() + ":" + toxiproxy.getMappedPort(8666) + "/stream"),
                session -> session.receive()
                    .map(WebSocketMessage::getPayloadAsText)
                    .filter(msg -> msg.contains("sequence"))
                    .take(3)
                    .collectList()
            )
        )
        .assertNext(messages -> {
            assertThat(messages)
                .extracting(json -> JsonPath.read(json, "$.sequence"))
                .containsExactly(1, 2, 3);
        })
        .verifyComplete();
    }
}

실제 상황

고빈도 거래 플랫폼이 시장 데이터 피드를 위해 REST 폴링에서 WebSocket 스트리밍으로 마이그레이션하고 있었습니다. QA 팀은 가격 업데이트가 시장 변동성 증가로 인해 초당 10k+ 메시지가 발생하는 경우에도 올바른 시간 순서로 도착하는 것을 검증해야 했습니다. 기존의 REST 스위트는 WebSocket이 몇 초 만에 처리할 수 있는 시나리오를 검증하는 데 8분이 걸렸으며, 자동화 프레임워크의 완전한 아키텍처 개편이 필요했습니다.

초기 구현은 메시지를 기다리기 위해 **Thread.sleep()**를 사용하여 30초의 테스트 스위트와 40%의 균열 비율을 초래했습니다. 병렬 실행은 테스트가 공유 Redis pub/sub 백플레인으로부터 서로의 메시지를 소비하게 했습니다. 이진 Protobuf 페이로드는 Base64 문자열로 비교되고 있어 반복 요소에서 비결정적인 필드 순서로 인한 실패를 초래했습니다.

팀은 메시지를 수집하고 시간 초과로 폴링하기 위해 LinkedBlockingQueue를 사용하는 것을 고려했습니다. 이는 단순한 주장 로직을 제공했지만 비결정적인 지연을 초래했습니다. 테스트는 여전히 느렸고, 큐 비우기에서 경합 조건이 발생하여 메시지가 소비보다 더 빨리 도착할 때 간헐적인 주장 실패를 초래했습니다. 이 접근 방식은 진정한 순서 의미를 검증하는 데 실패하여 최종적인 수신만 검증했습니다.

WireMock 또는 MockWebServer를 사용하여 캡처된 WebSocket 프레임을 재생하는 것은 결정론적인 실행과 빠른 피드백을 제공했지만, TCP 패킷 손실이나 재연결 로직과 같은 실제 네트워크 복원력 문제를 포착하지 못했습니다. 모의 객체는 애플리케이션 서버에서 실제 Netty 핸들러 로직을 실행하지 않아 재연결 버그가 프로덕션에 도달하도록 허용했습니다.

Reactor의 TestScheduler를 사용하여 프로그래밍 방식으로 시간을 조작하고 Toxiproxy 뒤에서 실제 WebSocket 서버를 실행하는 TestContainers를 구현하면 실시간 네트워크 동작을 검증하면서 밀리초 단위의 빠른 실행을 가능하게 했습니다. 가상 시간 스케줄러는 5분 타임아웃 윈도우를 50ms 이내에 테스트할 수 있게 하며, Toxiproxy는 정확한 대기 시간과 대역폭 제한을 주입했습니다. 이 접근 방식은 초기 설정이 더 요구되었지만 최고의 충실도를 제공했습니다.

팀은 생산 충실도를 보존하면서 실행 속도를 희생하지 않은 비동기 가상 시간 접근 방식을 선택했습니다. 모의 객체와 달리 실제 Netty 파이프라인과 재연결 핸들러를 검증했습니다. 차단 대기열과 달리 Flux 시퀀스 연산자를 통해 결정론적 순서 주장을 제공했습니다. Docker 네트워크에 의해 제공되는 격리는 병렬 실행 충돌을 제거했습니다.

테스트 실행 시간이 스위트당 4분에서 12초로 단축되었습니다. CI 실행 3개월 동안 불안정성이 제로로 감소했습니다. 프레임워크는 애플리케이션이 TCP 재연결 이벤트 후 메시지를 중복 제거하지 못하는 중요한 버그를 발견했으며, 이는 이전의 수동 테스트에서 놓쳤던 것입니다. 이 솔루션은 포트 충돌 없이 50개의 병렬 CI 작업자를 처리했습니다.

후보들이 종종 놓치는 점

병렬로 WebSocket 테스트를 실행할 때 메시지 교차 오염을 어떻게 방지합니까?

후보들은 종종 클라이언트 인스턴스에서 synchronized 블록이나 ReentrantLock을 사용하자고 제안합니다. 이 방법은 실행을 직렬화하고 병렬 CI의 목적을 무너뜨립니다. 올바른 접근 방식은 건축적 격리를 포함합니다: 각 테스트 클래스는 전용 네트워크 네임스페이스와 동적 포트 할당과 함께 자체 TestContainer를 인스턴스화합니다. 테스트가 고유한 상관관계 식별자로 태그가 달린 메시지만 구독하도록 UUID 기반 라우팅 키를 사용합니다. 이는 성능 병목 현상 없이 공유 상태가 제로임을 보장합니다.

WebSocket 이진 프레임을 Base64 문자열로 비교할 경우 잘못된 음성을 유발하는 이유와 이진 페이로드를 검증하는 방법은 무엇입니까?

Protobuf 또는 MessagePack 페이로드의 Base64 인코딩은 구현 간에 다를 수 있는 와이어 형식 메타데이터(필드 순서, 알 수 없는 필드 보존)를 포함합니다. 문자열 비교는 의미적으로 동일한 메시지가 비슷한 이진 표현을 가질 때 실패합니다. 대신 공식 Protobuf 컴파일러를 사용하여 ByteBuf를 생성된 Java/Kotlin 클래스로 역직렬화한 다음 AssertJ의 재귀 비교를 사용하여 필드별로 깊은 비교를 수행합니다. 알 수 없는 필드의 경우 proto 동등성을 올바르게 처리하는 ProtoTruth(Google의 Truth 라이브러리 확장)를 사용합니다.

애플리케이션 방화벽 규칙을 수정하지 않고 WebSocket 테스트에서 네트워크 파편화를 어떻게 시뮬레이션합니까?

iptables를 수정하거나 애플리케이션 코드를 수정하려면 루트 권한이 필요하고 환경이 이동합니다. 후보들은 종종 Toxiproxy나 Pumba(Docker를 위한 혼돈 테스트 도구)를 놓칩니다. 이들은 테스트 네트워크에서 사이드카 컨테이너로 실행되어 REST API를 통해 대기 시간, 대역폭 제한 및 연결 재설정을 프로그래밍 방식으로 주입할 수 있습니다. WebSocket 클라이언트를 프록시 엔드포인트를 통해 연결하도록 구성합니다. 테스트 중에 유해 엔드포인트를 호출하여 연결을 차단하거나 100% 패킷 손실을 유도한 후 클라이언트가 예상 재연결 백오프 전략을 촉발하고 올바른 메시지 순서 식별자로 계속됨을 확인합니다.