답변.

테스트 고정 장치 구현은 테스트 시나리오에 대한 환경, 데이터 및 의존성을 준비하는 자동화 테스트의 핵심 요소입니다.

문제의 역사 고정 장치는 자동화 테스트에서 테스트 실행 전에 환경을 사전 설정하고 정리하는 중앙 집중식 관리 방법으로 등장했습니다. 이를 통해 팀은 코드가 지속적으로 변경될 때 테스트의 일관성과 예측 가능성을 달성할 수 있었습니다.

문제 올바른 고정 장치가 없다면 자동화 테스트는 불안정해지고 서로 의존하게 되어 병렬 실행 시 서로 방해하며 기술 부채를 증가시킵니다 (setup/teardown 논리가 중복되고 확장됩니다).

해결책 테스트 프레임워크에서 제공하는 표준 고정 장치 메커니즘을 사용하십시오 (예: JUnit의 @BeforeAll, @BeforeEach 또는 pytest의 conftest.py). 고정 장치를 구성 가능하고 격리된 상태로 유지하는 것을 목표로 하십시오:

테스트에 실제로 필요한 것만 올리고 내립니다;
복잡한 케이스에는 데이터/객체를 동적으로 생성하고 이후 정리합니다;
준비 코드를 한 곳에 유지합니다;

핵심 특징:

각 테스트에 대한 환경의 격리;
테스트 간의 의존성 최소화;
고정 장치의 중앙 집중화 및 확장성.

속임수 질문들.

고정 장치가 생성한 객체를 하나의 테스트에서 수정할 수 있습니까? 다음 테스트가 필요하다면요?

아니요, 그렇게 되면 테스트가 서로 의존하게 됩니다: 하나의 테스트에서 변경한 사항이 다른 테스트를 깨뜨릴 수 있습니다. 각 테스트에 대해 새로운 객체를 사용하는 것이 좋거나, 각 실행 후 변경 사항을 롤백하는 것이 좋습니다.

자동화 테스트 실행 시작 시 데이터베이스를 "한 번에" 로드하여 과정을 가속화할 수 없나요?

이러한 접근은 불안정한 테스트와 잡기 어려운 버그로 이어질 수 있습니다. 데이터가 테스트 간에 "고착"되고, 진행 순서가 중요해질 것입니다.

전체 테스트 세트를 위해 하나의 전역 고정 장치를 사용할 수 있습니까?

아니요, 전역 고정 장치는 완전히 독립적인 테스트에만 허용됩니다. 일반적으로 이러한 접근은 테스트 간의 상호 영향을 초래하여 분석 및 유지 관리가 어렵게 됩니다.

일반적인 오류 및 안티 패턴

전역/청소할 수 없는 고정 장치 사용
각 테스트에서 데이터 준비 논리 중복
청소할 수 없는 테스트 데이터로 인한 "오염"

실제 예

부정적 사례

프로젝트에서 시간을 절약하고 모든 테스트에서 동일한 데이터베이스를 사용하며 각 테스트 후 변경 사항을 롤백하지 않기로 결정했습니다. 동일한 데이터를 변경하는 테스트가 등장한 후, 테스트는 서로의 실행 순서에 따라 "실패"하기 시작했습니다.

장점:

빠른 실행 (이론적으로)
정리에 필요한 코드가 적음

단점:

실패 원인 찾기가 어려움
테스트가 서로 의존함
확장 문제

긍정적 사례

팩토리 고정 장치를 사용했습니다: 각 테스트가 자신의 데이터를 생성하고 완료 후 삭제합니다. 이전의 버그는 더 이상 재현되지 않으며 테스트 순서는 중요하지 않습니다.