한 테스트가 다른 테스트를 깨뜨릴 때

실패가 연쇄적으로 나타나는 이유

2021년 6월 18일의 Factorio 개발 기록 #366은 테스트 사이의 의존성을 다룹니다. 여기서 말하는 의존성은 앞 테스트가 남긴 월드 상태를 다음 테스트가 재사용하는 문제와 다릅니다. 전신주 연결을 검사하는 상위 테스트도 지도에서 개체를 찾는 하위 기능이 제대로 작동해야 성공한다는 뜻입니다. 하위 검색 기능 하나가 깨지면 여러 연결 테스트가 함께 실패할 수 있습니다.

Wube는 모든 하위 기능을 모의 객체로 바꾸기보다, 실제 기능을 연결해 검사하는 테스트도 유지했습니다. 대신 의존 관계에 따라 실행·결과 표시를 구성해 더 단순한 실패부터 조사할 수 있도록 했습니다. 실패한 테스트가 많다는 사실만으로 서로 다른 버그가 그만큼 생겼다고 판단하지 않는 접근입니다.

상태 오염과 기능 의존성을 구분하기

이 구분은 테스트를 고치는 방법에도 영향을 줍니다. 지도 검색 자체가 잘못됐다면 테스트마다 새 월드를 만들어도 검색 결함은 남습니다. 반대로 다른 테스트가 남긴 전역 변수 때문에 실패한다면 의존성 그래프만 정리해서는 해결되지 않습니다.

pytest의 공식 문서는 실행 순서에 의존하거나 이전 테스트의 데이터를 정리하지 않아 발생하는 불안정한 테스트를 별도 원인으로 설명합니다. 따라서 실패 로그에는 선행 기능의 실패 여부와 테스트 환경 초기화 여부를 나누어 남기는 편이 좋습니다. 이 문서는 상태 격리에 관한 보충 근거이며, Factorio가 pytest를 사용한다는 뜻은 아닙니다.

GUI도 실제 입력 경로를 검사합니다

원문에 공개된 GUI 테스트는 빠른 접근 슬롯에 필터를 지정한 다음 클릭 입력을 보내고 필터가 제거됐는지 확인합니다. 내부 값을 곧바로 지우는 대신 입력 처리 계층을 통과시키는 구조입니다. 이런 검사는 버튼과 명령 처리 사이의 연결 오류를 발견하는 데 의미가 있습니다.

다만 전체 경로 검사가 모든 단위 테스트를 대신하지는 않습니다. 프로젝트에서 적용한다면 데이터 검색, 명령 처리, GUI 입력을 각각 관찰할 수 있게 나누고, 어떤 하위 검사가 통과한 상태인지 보고서에 보여주는 방식부터 검토할 수 있습니다.

직접 비교해 볼 절차

아래는 실행 결과가 아닌 재현 실험 제안입니다. 먼저 작은 지도 검색 테스트와 이를 사용하는 연결 테스트를 준비합니다. 검색 조건에 의도적인 오류를 넣고 두 테스트의 실패가 어떻게 연결되는지 확인합니다. 다음에는 검색 코드를 복구한 뒤 전역 상태 초기화만 누락해 순서 의존 실패를 별도로 만들어 봅니다.

각 경우를 단독 실행과 전체 실행으로 비교하면 기능 결함과 환경 오염을 구분하는 연습이 됩니다. 목표는 실패 수를 줄여 보이는 것이 아니라, 최초 원인에 도달하는 시간을 줄이는 것입니다. 이 글에서 확인한 구현 근거는 개발자가 공개한 설명과 코드 예시이며, Factorio 내부 테스트 전체를 실행하거나 검토한 것은 아닙니다.

출처

• Factorio 공식 개발 기록 #366
• 보충 자료: pytest 공식 테스트 문서