일부 Geb 기능 테스트는 Chrome과 함께 전달되지만 PhantomJS에서는 실패하고 다른 모든 변수는 일정한 것으로 나타났습니다. 이는 주로 비동기 활동이있는 페이지에서 발생합니다. $(selector).click()에 대한 호출은 DOM을 업데이트하는 이벤트 처리기를 트리거하고 DOM 업데이트는 $(anotherSelector).click()을 호출하기 전에 완료해야합니다.Geb 테스트가 Chrome을 통과하고 PhantomJS가 실패 함
waitFor을 적극적으로 사용하여 PhantomJS 테스트를 다시 통과시킬 수는 있지만 Chrome 드라이버가 아닌 PhantomJS GhostDriver가 필요한 이유는 알 수 없습니다.
불행히도 최소한의 테스트 케이스는 아직 만들지 못했지만 응용 프로그램과 분리되어 있습니다.
내가 할 수있는 유일한 조언을 항상 비동기 활동 주위에 당신의 테스트에서 어떤 조치가 보호되어 있는지 확인하는 것입니다 waitFor 진술. 테스트가 테스트 페이지에서 새/수정 된 요소에 액세스하려고 시도하기 전에 한 드라이버가 비동기 작업을 완료하기에 충분히 빠르지 만 다른 테스트는 그렇지 않은 문제를 피할 수 있습니다. 비동기 활동을 중심으로 waitFor을 사용하지 않으면 일반적으로 속도가 느린 CI에서 테스트를 시작하면 테스트 페이지에서 비동기와 관련된 더 많은 실패를 볼 수 있습니다.
waitFor을 사용하여 테스트의 모든 비동기 활동을 공격적으로 감시하는 것도 고려하지 않습니다. waitFor은 주기적으로 조건을 폴링하고 조건이 충족되는대로 계속됩니다. 따라서 브라우저가 빠르면 처음으로 waitFor 투표를하기 전에 페이지가 업데이트되고 속도가 현저히 저하되지는 않습니다. 그렇지 않은 경우 비동기 조치가 완료되고 조건이 충족되었는지 확인하기위한 재 시도가 있음을 보증합니다. 내가 공격적이라고 느낀 것은 30 대와 같이 엄청나게 높은 타임 아웃을 사용하는 것입니다. 테스트가 실패하면 오랜 시간이 걸릴 것입니다.
나는 IE와 Firefox조차도 최근 경험이있다.
물론입니다. 그래서 수동으로 시도하고 차이가 무엇 관찰,이 같은 것을 사용 :
if(System.properties["geb.env"]=="chrome") { $(selector).click() } else { // Do something else }
내가 묻는 이유는 * 왜 * Chrome보다 PhantomJS에서 waitFor가 필요한지입니다. – wrschneider
왜? 그게 재미있는 일이야! Geb의 커미터가 알기에 가장 좋은 사람들이라고 생각합니다! 예를 들어 Chrome은 geb의 Firefox보다 더 빨리 작동하며 Firefox는 Chrome보다 waitFor가 더 많이 필요하지만 모든 브라우저가 비슷하게 작동하는지 확인하는 것이 좋습니다. –
감사합니다. @erdi. 그게 내가 아는거야. waitFor()는 수면과 같은 종류의 함수가 아닙니다. –
내가 이해하지 못하는 이유는 Chrome에서 테스트를 통과하기 위해 waitFor *가 필요하지 않은 이유입니다. – wrschneider