대기(Waits)

GitLab QA 프레임워크에서 Capybara의 대기 메커니즘과 하드 슬립(Hard Sleep) 사용 방법을 설명합니다.

모든 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)하는 것보다 낫습니다.