테스트 모범 사례 # 테스트 설계 # GitLab에서 테스트는 나중에 추가하는 것이 아니라 최우선으로 고려하는 요소입니다. 기능 설계를 고민하듯 테스트 설계도 신중하게 접근하는 것이 중요합니다. 기능을 구현할 때는 올바른 방법으로 올바른 기능을 개발하는 것을 고려합니다. 이를 통해 범위를 관리 가능한 수준으로 좁힐 수 있습니다. 기능에 대한 테스트를 구현할 때는 올바른 테스트를 개발하면서 동시에 테스트가 실패할 수 있는 모든 중요한 경우를 다뤄야 합니다. 이로 인해 범위가 관리하기 어려운 수준으로 급격히 넓어질 수 있습니다. 테스트 휴리스틱(heuristics)은 이 문제를 해결하는 데 도움이 됩니다. 이는 코드에서 버그가 나타나는 일반적인 방식들을 간결하게 다룹니다. 테스트를 설계할 때는 잘 알려진 테스트 휴리스틱을 검토하여 테스트 설계에 참고하세요. Handbook의 Testing Guide 에서 유용한 휴리스틱을 찾을 수 있습니다. RSpec # RSpec 테스트를 실행하려면: # run test for a file bin/rspec spec/models/project_spec.rb # run test for the example on line 10 on that file bin/rspec spec/models/project_spec.rb:10 # run tests matching the example name has that string bin/rspec spec/models/project_spec.rb -e associations # run all tests, will take hours for GitLab codebase! bin/rspec Guard 를 사용하면 변경 사항을 지속적으로 모니터링하고 일치하는 테스트만 실행할 수 있습니다: bundle exec guard spring과 guard를 함께 사용할 때는 spring을 활용하기 위해 SPRING=1 bundle exec guard 를 대신 사용하세요. 일반 가이드라인 # 단일 최상위 RSpec.describe ClassName 블록을 사용하세요. 클래스 메서드를 설명할 때는 .method 를, 인스턴스 메서드를 설명할 때는 #method 를 사용하세요. 분기 로직을 테스트할 때는 context 를 사용하세요( RSpec/AvoidConditionalStatements RuboCop Cop - MR ). 테스트 순서를 클래스 내 순서와 일치시키도록 노력하세요. 가능한 경우 테이블 기반 테스트 를 사용하세요. 단계를 구분하기 위해 빈 줄을 사용하여 Four-Phase Test 패턴을 따르도록 노력하세요. 'localhost' 를 하드코딩하지 말고 Gitlab.config.gitlab.host 를 사용하세요. 테스트의 리터럴 URL에는 example.com , gitlab.example.com 을 사용하세요. 이렇게 하면 실제 URL을 사용하지 않을 수 있습니다. 시퀀스 생성 속성의 절대값에 대해 단언(assert)하지 마세요( Gotchas 참고). expect_any_i
