RSpec 구조에 대한 이야기

 RSpec을 공부할 때 좋은 자료들은 모두 영어로 되어있어서 레퍼런스들과 RSpec 관련 책, 문서들을 읽느라 힘들었었다. 테스트인데 이렇게까지 많은 글들을 읽어봐야 해?라고 생각하며 많은 레퍼런스와 자료를 참고하였다. 그 경험을 바탕으로 이번 글에서는 먼저 RSpec을 어떠한 구조로 작성하는 것이 좋은지에 대해 설명해 보겠다.

 아마 RSpec을 처음 공부하시면 어떠한 구조로 작성해야지 베스트 프랙티스일까?라는 고민을 제일 먼저 하게 되실 거다. 나 역시 그랬으니까. 이번 글은 크게 가상 객체를 만들 때 사용해야 하는 gem, 통합 테스트를 할 때 사용해야 하는 spec, 유닛 테스트할 땐 어떻게 구조화하면 되는지에 대해 설명하겠다. 이번 글은 나무보단 숲에 대한 이야기이므로 사용법에 대한 내용은 다음에 자세히 하나씩 다룰 예정이다.

 본론에 들어가기에 앞서 RSpec은 무엇을 지향할까? 구현 테스트보단 행동 테스트에 초점을 맞추고 개발자가 편하게 테스트를 할 수 있게 지원해주는 API다. TDD로 하고 싶다면 TDD로 개발해도 된다. 각 개발자에게 맞는 방식으로 진행하면 될 것이라 생각한다. 구현보단 행동에 초점을 맞추었단 의미는 하나하나 작은 단위보단 그 단위가 모인 한 덩어리를 테스트하는 것을 지향한다. 여기서 한 덩어리는 함수일 수도 있고 한 기능일 수도 있다.

 

1. FactoryBot

 팩토리봇은 rspec을 테스트할 때, rspec reference와 많은 rspec 전문가들이 추천하는 방법이다. 팩토리봇으로 만들 때, Faker라는 가상 객체를 만들어주는 gem이 있다. 이 faker, factoryBot, ruby가 제공하는 메서드를 통해서 가상 인스턴스 변수를 만들어주면 된다.

2. 통합 테스트

1) feature spec

 첫 번째로, 가장 많이 사용되어져 왔고 그만큼 기술적으로 검증이 되어 있다는 것이 가장 큰 장점이다.

 두 번째로는 피처 스펙에 대한 설명과 자료가 많다는 것이다. 정말 질 좋은 문서들이 많다. 그래서 RSpec에 대한 이해도를 빠르게 높일 수 있다.

 세 번째로는 터미널에서 보는 테스트와 웹 브라우저에서 보는 테스트 결과를 분리할 수 있다. webdriver를 gem으로 추가하고 약간의 config만 해주면 웹 브라우저에서 볼 수 있게 설정할 수 있고, 이걸 하지 않는다면 터미널에서 테스트 결과물을 확인할 수 있다.

 네 번째로는 capybara, databasecleaner 설정을 반드시 해줘야 한다. 그래야 테스트에서 실제 페이지에 방문하는 테스트를 볼 수 있고, db 트랜잭션을 활용할 수 있다.

2)  system spec

 2017년 10월쯤 시스템 스펙이 나오고 RSpec 팀에서 공식적으로 추천하고 있는 스펙이다. RSpec reference 페이지에 들어가 보면 시스템  스펙이 피처 스펙보다 뭐가 더 좋은지 구구절절 써져있는데, 쭉 읽어보면 핵심은 Third Party Extension이 필요 없다는 것이다. 그래서 설정을 최소화할 수 있다는 것을 강점으로 내세운다. 또한 내부적으로 설정이 다 되어 있어서 selenium driver와 chrome browser 가 디폴트 설정으로 되어있다.

3) request spec

 컨트롤러가 해주는 역할을 테스트할 수 있는 spec이다. status code, redirection, text in the response body 등을 확인할 때 쓰인다. 보통 status code를 확인하는 용도로 쓰인다.

4) feature vs system vs request

 이 세가지 중 무엇을 선택하던 사용자 마음이다. 그런데 request spec을 선택한다면, 반드시 피처나 시스템 스펙 테스트를 또 진행해야 만한다. 그러니 통합 테스트는 피처나 시스템 스펙 중 고민하시는 것을 추천드리고, 하나만 선택하라고 한다면 feature spec을 선택하겠다.

3. 유닛 테스트

 공식 문서에서 보면 레일즈에서 자주 쓰이는 model spec에 대한 내용은 있어도 service spec에 대한 내용은 없다. 그 이유가 아마도 구현보다 행동에 초점을 맞춘 RSpec 철학 때문이라고 생각한다. 그래서 직접 서비스 스펙을 만들어서 써줘야 한다. 이때 특히, databaseCleaner gem 설정이 정말 중요하다. 그리고 팩토리봇 간 연관관계를 잘 설정해 놓아야 서비스 로직을 잘 테스트해볼 수 있다. 또한 꼭 service 파일이 아니더라도 여러분이 테스트하고 싶은 내용에 대한 디렉터리를 만들어서 거기에 직접 테스트를 하면 된다.

 

 

references

 

https://github.com/thoughtbot/factory_bot/blob/master/GETTING_STARTED.md

: factorybot

relishapp.com/rspec/rspec-rails/v/4-0/docs/feature-specs/feature-spec

https://rubydoc.info/gems/rspec-rails/frames#feature-specs

books.thoughtbot.com/assets/testing-rails.pdf

: rspec