모든 Capybara Node Finder는 대기 메커니즘을 활용합니다.

Capybara API에 따르면 -

드라이버가 JavaScript를 실행할 수 있는 경우, find는 일정 시간 동안 대기하면서 엘리먼트를 찾을 때까지 또는 시간이 만료될 때까지 계속해서 엘리먼트 탐색을 재시도합니다. find가 대기하는 시간의 길이는 Capybara.default_max_wait_time을 통해 제어되며 기본값은 2초입니다. find는 all과 동일한 옵션을 사용합니다.

이상적으로는 GitLab QA Framework가 하드 슬립을 피하기 위해 자체적인 명시적 대기를 구현해야 하지만, 현재는 그렇지 않습니다.

하드 슬립(Hard Sleeps)#

qa/qa/page/base.rb

def wait(max: 60, time: 0.1, reload: true)
  ...
end

• max: 주어진 블록이 충족될 때까지 대기할 최대 시간(초)을 지정합니다.

• time: 초 단위의 슬립 인터벌/폴링 시간입니다. 이 시간이 max에 도달하면 대기는 false를 반환합니다.

• reload: 대기가 충족되지 않으면, :reload가 true로 설정된 경우 테스트는 슬립 후 페이지를 다시 로드합니다.

준비 상태를 명시적으로 대기하기#

페이지 액션은 흔히 자신이 트리거한 백엔드 작업이 끝나기 전에 반환됩니다. 테스트가 이 간극 사이에 상태를 읽으면 결과가 타이밍에 좌우되어 테스트가 불안정(flaky)해집니다. 이를 피하려면 리소스에 대해 작업하거나 검증하기 전에 작업이 완료되었음을 확인해 주는 신호를 대기해야 합니다.

프레임워크는 얼마나 오래 대기할지 추측하는 대신 특정 조건을 폴링하는 여러 헬퍼를 제공합니다. 예를 들어 Support::Retrier와 Support::Waiter는 작업이 성공할 때까지 재시도하며, 리소스는 runner.wait_until_online과 같은 준비 상태 확인 메서드를 노출합니다:

# Wait until the runner reports itself online before the test depends on it.
runner.wait_until_online

가시적인 엘리먼트, 리소스 상태, API 응답처럼 대기하려는 작업을 반영하는 신호를 선택하세요. 고정된 sleep은 작업이 선택한 시간보다 더 오래 걸릴 수 있으므로 신뢰할 수 있는 신호가 아니며, 준비 상태를 대기하는 용도로 사용하지 마세요.

대기가 여전히 타임아웃된다면, 먼저 올바른 신호를 대기하고 있는지 확인하세요. 신호를 바로잡는 것이 타임아웃을 늘리는 것보다 더 신뢰할 수 있으며, 두 방법 모두 테스트를 격리(quarantine)하는 것보다 낫습니다.