테스트에서 너무 많은 추상화를 피하는 이유는 무엇입니까?

소개

프로덕션 코드가 있고 테스트 코드가 있습니다. 프로덕션 코드는 프로덕션 환경에서 실행되는 코드베이스의 모든 부분을 나타냅니다. 마찬가지로 테스트 코드는 테스트 코드를 통해 프로덕션 코드가 실행되는 테스트 환경에서만 실행되는 코드베이스의 모든 부분을 나타냅니다.

테스트 코드는 명확하고 읽기 쉽고 진행 상황을 이해하기 쉬워야 합니다. 공유 예제와 같은 테스트 추상화는 일반적으로 테스트 코드에서 필요한 것과 반대입니다.

테스트 코드를 건조하지 않는 이유는 무엇입니까?

테스트 코드에서 여러 추상화로 테스트된 프로덕션 코드를 리팩토링하는 것이 더 어려워집니다. 이는 하나의 단일 테스트 추상화가 테스트 코드의 여러 위치에서 사용되어 잠재적으로 변경으로 인해 일부 테스트가 중단되지만 모든 테스트는 중단될 수 있기 때문입니다. 마지막으로 테스트 추상화에서 리팩토링 작업을 트리거하거나 추상화 사용을 중지하지 못한 테스트를 업데이트하면 더 이상 테스트에 적합하지 않을 수 있습니다.

실패가 있는 테스트 보고서는 읽기가 더 어렵습니다. 추상화를 사용하는 테스트가 추상화 내부에서 실패한 경우 보고서는 먼저 실패한 위치를 표시하며, 그 위치는 추상화 내부입니다. 개발자는 어떤 테스트가 실제로 실패했는지 알아내기 위해 어떤 테스트가 추상화라고 부르는지 확인하기 위해 스택 추적을 읽어야 합니다.

이것은 RSpec의 Shared Examples의 출력입니다.

Finished in 3.17 seconds (files took 2.49 seconds to load)
47 examples, 5 failures

Failed examples:

rspec ./spec/requests/api/v1/users_spec.rb[1:2:2:2:1:1:1] # Api::V1::Users PATCH #update behaves like ...
rspec ./spec/requests/api/v1/users_spec.rb[1:2:4:1:1:1] # Api::V1::Users PATCH #reset_change_email behaves like ...
rspec ./spec/requests/api/v1/users_spec.rb[1:2:5:1:1:1:1] # Api::V1::Users PATCH #request_remove_user behaves like ...
rspec ./spec/requests/api/v1/users_spec.rb[1:2:1:1:1:1] # Api::V1::Users GET #show behaves like ...
rspec ./spec/requests/api/v1/users_spec.rb[1:2:3:1:1:1] # Api::V1::Users PATCH #reset_api_key behaves like ...

실패가 발생한 위치를 알 수 있다면 맥주는 나에게 달려 있습니다.

오해하지마

테스트 코드에 대한 너무 많은 추상화는 읽고 있는 책의 모든 단어를 강조 표시하는 것과 같습니다. 가장 중요한 부분만 강조하고 싶습니까?

테스트 코드가 매우 유사하기 때문에 모든 것을 추상화하고 싶지는 않지만 테스트 코드를 가능한 한 명확하고 읽기 쉽게 유지하는 동시에 테스트 케이스에 실제로 의미가 없는 부분에 대한 추상화를 제공합니다. 예를 들어 테스트 코드를 위한 객체를 생성하기 위한 팩토리 패턴은 완벽합니다 – re: FactoryBot . Custom matchers 또한 테스트 코드를 명시적이고 선언적으로 유지하면서 추상화를 도입하는 유효한 방법입니다.

요약하면 테스트 코드의 의미 없는 부분에 대한 추상화는 유효하고 정말 유용합니다. 시스템의 실제 동작을 설명하는 테스트 코드의 추상화는 결코[ * ] 좋지 않습니다.

* 나는 지난 달에 코드 리뷰 제안에서 공유 예제를 작성했으며, 그걸로 살 수 있습니다.