이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
UI 테스트 자동화에서 유지보수성을 높이기 위해 페이지 오브젝트 패턴을 도입했습니다. 화면 요소를 클래스로 추상화하면 UI가 바뀌어도 테스트 코드 수정이 한 곳으로 집중됐고, 테스트 로직과 요소 선택 코드가 분리돼 가독성이 좋아졌습니다.
API 테스트에서는 테스트 데이터 전략이 핵심이었습니다. 각 테스트가 독립적으로 동작하려면 데이터를 공유하지 않아야 하기 때문에, 테스트 실행 전 데이터를 생성하고 실행 후 정리하는 구조를 만들었습니다. 상태가 남아 있는 경우 다른 테스트에 영향을 주는 문제가 생겼습니다.
테스트 결과 리포트도 자동화했습니다. 실패한 케이스의 스크린샷과 요청·응답 로그를 함께 저장해 원인 파악 시간을 줄이는 구조를 갖췄습니다. CI 파이프라인에서 실패 시 슬랙으로 알림이 오도록 연결해 빠른 대응이 가능했습니다.
테스트 자동화를 구축하면서 잘 동작하지 않는 영역이 있다는 것을 경험으로 알게 됐습니다. UI 자동화는 화면 구조가 바뀔 때마다 테스트가 깨지는 경우가 많아서, 테스트를 유지하는 비용이 처음 예상보다 높다는 것을 알게 됐습니다. 페이지 오브젝트 패턴으로 어느 정도 줄였지만, 애니메이션이나 타이밍에 의존하는 테스트는 환경에 따라 불규칙하게 실패하는 경우가 있었습니다.
E2E 테스트보다 API 단위 테스트가 유지보수 비용이 낮다는 것을 경험하면서, 어떤 레이어에서 어떤 종류의 테스트를 두는지를 고려하게 됐습니다. 테스트 자동화는 많이 쌓는 것보다 어떤 테스트를 어느 계층에 두는지가 더 중요하다는 것을 배웠습니다.
REST API 테스트 외에 GraphQL API 테스트를 처음 구성하면서 다른 점이 많았습니다. REST는 엔드포인트마다 다른 테스트를 작성했지만, GraphQL은 단일 엔드포인트에서 쿼리와 변수의 조합이 테스트 범위를 결정했습니다. 스키마가 명시돼 있어서 Introspection으로 사용 가능한 필드와 타입을 먼저 파악하고 테스트를 짜는 것이 가능했습니다.
응답 구조가 요청 쿼리에 따라 달라지기 때문에, 테스트마다 기대 응답을 정밀하게 정의해야 한다는 것을 알게 됐습니다. GraphQL 테스트는 REST보다 스키마 이해가 먼저 필요하지만, 스키마가 있으면 테스트 범위를 체계적으로 잡을 수 있다는 것을 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 CJ올리브영 SW·IT 일반 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.