픽스처 문제에 대한 잘못된 접근 방식

대규모 테스트 스위트에서 픽스처가 동결되는 문제를 해결하기 위해 다음과 같은 접근 방식이 흔히 관찰되지만, 이는 문제를 악화시킬 수 있습니다.

• 새로운 픽스처 생성: 기존 픽스처 재사용의 어려움으로 인해 새로운 테스트마다 픽스처를 추가하는 것은 픽스처 크기를 불필요하게 키우고 관리 복잡성을 증대시킵니다.

• 테스트 코드 내 픽스처 레코드 수정: 테스트 내부에서 데이터베이스를 임시로 수정하는 것은 팩토리 패턴을 비체계적으로 구현하는 것과 같으며, 일관성을 해치고 유지보수를 어렵게 합니다.

올바른 해결책: 오직 테스트하려는 것만 테스트하라

테스트는 오직 코드의 특정 속성을 검증하도록 설계되어야 합니다. 이 원칙을 적용하여 픽스처 동결 문제를 효과적으로 해결할 수 있습니다. 핵심은 각 테스트가 무엇을 검증하려는지 명확히 하고, 그 속성만을 직접적으로 테스트하는 코드를 작성하는 것입니다.

예시 1: 컬렉션 내용 테스트

모델의 스코프처럼 컬렉션의 내용을 테스트할 때, 전체 컬렉션을 고정된 배열과 비교하는 대신 특정 요소의 포함 여부를 검증합니다. ```ruby # 나쁜 예: 전체 배열 비교는 새로운 요소 추가 시 테스트를 깨뜨림 # assert_equal [projects(:active1), projects(:active2)], Project.active

좋은 예: 특정 요소의 포함/미포함 여부만 검증하여 유연성 확보

test “active scope returns active projects” do active_projects = Project.active assert_includes active_projects, projects(:active1) assert_includes active_projects, projects(:active2) refute_includes active_projects, projects(:inactive) end ``` 이 방식은 새로운 활성 프로젝트가 픽스처에 추가되더라도 기존 테스트가 실패하지 않도록 하여 픽스처의 유연성을 확보합니다.

예시 2: 컬렉션 순서 테스트

컬렉션의 정렬 순서를 테스트할 때도 전체 배열과 비교하는 대신, 정렬 속성 자체를 검증합니다. ```ruby # 나쁜 예: 전체 배열 비교는 다른 요소 추가/변경 시 테스트를 깨뜨림 # assert_equal Project.ordered, [projects(:aardvark), projects(:active1), projects(:inactive)]

좋은 예: 컬렉션이 정렬되어 있는지 자체적으로 확인

test “ordered sorts by project name” do names = Project.ordered.map(&:name) assert_equal names, names.sort end ``` 특정 정렬 버그(예: 비라틴 문자 정렬)를 테스트하는 경우, 해당 특정 케이스에만 집중하여 테스트를 작성함으로써 테스트의 정밀도를 높이고 픽스처가 불필요하게 동결되는 것을 방지합니다.