삽질도 방향이 필요하다

E2E 서드 파티 서비스 연동

WebdriverIO로 웹 모바일 E2E를 구축했고 서드 파티 서비스 연동 작업을 진행하던 중, 정말인지 알 수 없는 에러로 인해 고통스러운 시기가 있었다. 동작이 되는 상황도 이상했고 안 되는 상황도 이상한, 그러한 상황들로 가득했다. 끝내 동작 원리를 처음부터 하나씩 다시 분석했고 결국 해결하게 되었다. 현재까지 발생한 모든 문제를 해결하진 못했지만 대부분의 이슈를 해결했고 삽질도 방향이 필요하다는 것을 배우게 되었다.

WebdriverIO에 BrowserStack을 연동하고 qTest 툴에서 자동화 테스트 케이스를 실행하는 환경을 구축하던 중에 expect() 성공 및 실패 케이스의 테스트 결과가 BrowserStack Status에 반영되지 않고 계속해서 Unmarked로 나타나는 이슈가 있었다. qTest 툴에서 테스트 실패 결과가 파싱 되지 않는 문제가, Unmarked 이슈와 연관이 있다고 가정하고, 모든 리소스를 처음 가정했던 원인을 해결하려는 시도에 쏟게 되었다.

뒤늦게 알게 된 사실이지만 애초에 BrowserStack의 Status와 qTest의 테스트 실패 결과 파싱 안 되는 문제는 서로 관련이 없었고, 원인은 전혀 다른 곳에 있었다. 3주 전으로 거슬러 올라가면 당시 프레임워크에 Git Action을 연동하여 코드 푸시할 경우의 워크플로우를 점검해보고자 샘플 Repo를 생성하여 진행하게 되었는데, 해당 기간 때 qTest Agent를 로컬에 셋업 하여 Agent 서버를 띄우고, 호스트를 셋업 하여 Agent와 매핑되는 Job이 어떻게 동작하는지를 파악하고 있었던 시기였다.

해당 작업 중에 qTest Agent의 Pre-Execute Script에 샘플 Repo로 생성해둔 프로젝트를 받아오는 스크립트를 넣게 되었다. 이후 샘플 Repo에서 2가지 작업을 병행하며 확인하던 중, expect() 구문에서 테스트 실패 발생 시 로그상으로 테스트가 바로 종료되지 않고, BrowserStack에서는 conf에 설정해둔 waitforTimeout 값에 도달할 때까지 실행되다가 결국엔 Time out이 발생하였다.

해당 이슈가 발생하고서야 BrowserStack의 Status를 유심히 살펴보게 되었는데, 지금껏 테스트 성공과 실패 시 Status가 계속해서 Unmarked로 나타났던 것이었다. 해당 문제로 인해 qTest에서도 오동작을 일으킨다고 판단했고 결과적으로 전혀 엉뚱한 방향으로 수많은 삽질을 거듭한 끝에 해답을 찾지 못했다(당연히).

현재까지 작업된 사항대로 워크플로우 구축을 일단락시키고자 마무리 작업을 준비하던 참에, 동작 원리를 다시 살펴본 결과, 그동안 이상하게만 느껴졌던 동작들이 이해되기 시작하였다. qTest와 브라우저 스택의 동작 원리를 분석했고 여러 테스트를 거듭한 끝에 BrowserStack의 Status 이슈는 프레임워크에 Allure-Report 셋업 과정에서 실수가 있었고, 브라우저 스택 관련된 conf.js 설정에 문제가 있었으며, package.json 파일의 devDependencies에서 "@wdio/allure-reporter" 버전에 문제가 있다는 걸 알게 되었다. 처음부터 셋업을 다시 진행했고 allure Report가 로컬에서 정상 동작하자 expect()에서 실패가 바로 끝나지 않는 이슈도 해결이 되었으며, 브라우저 스택에서의 Status 값도 테스트 결과에 따라 정상 표시되었다.

해당 이슈가 해결이 되자 qTest에서 테스트 실패 결과만 파싱 되지 않는 문제가 브라우저 스택의 Status와 관련이 없다는 것이 증명되었다. 이후 qTest Agent가 내뱉는 에러가 정의된 파일의 코드를 분석한 결과, 지금껏 qTest와 브라우저 스택의 동작 원리를 잘 못 이해하고 있었다는 생각이 들었고, 동작 원리를 하나씩 정리하게 되면서, 삽질도 방향이 필요하다는 것을 배우게 되었다. 그리고 그 방향은 아주 작은 것일지라도 추측이 아닌, 스스로 동작 원리를 파악하고 눈으로 확인해서 확신을 가질 때 조금이나마 올바른 방향으로 해결될 수 있다는 것을 배웠다.