본문 바로가기
Frameworks & Libraries/Ruby On Rails

[RoR, RSpec] RSpec 분석해 보기.

by 리나그(ReenAG) 2021. 12. 11.
728x90
반응형

주의! 본문 시작 전에 주저리가 있음. 넋두리를 보고 싶지 않으신 분은 아래로 넘길 것.

 이걸 가르쳐주신 분께도 이야기 한 내용이지만, PS에서만 테스트 하는 것이 중요한 것은 아니다. 아니, 어쩌면 당연한 내용이려나. 오히려 PS는 구현 / 테스트 / 디버그만을 극한으로 해야하는 분야이다. PS는 "혼자한다"는게 제일 큰 차이점인 것 같다. 물론 ExP활동을 하면서 다른 사람들과 함께 무언가를 만들어 본 경험 정도는 있지만... 이게 또 신선한 충격이다. 동아리 활동에서 "일일 빌드"라던가 "테스트"라던가... 그런걸 실천한 기억은 없다.

 만약 "남"이 이용해야하는 것을 그것을 넘어서서 "남과 함께" 만들어야한다면? 고려해야할게 정말 한두가지가 아니게 된다. 테스트를 맨날 손으로 돌리는 것은 비효율인 걸 넘어서서, 단지 "테스트를 통과 했습니다." 혹은 "기능이 완성되었습니다."라는 말만으로는 부족해지게 된다. (전혀 생각지 못하고 있었다. 언제나 염두에 두려고 노력하자.)


 "RSpec이란 Ruby 프로그래밍 언어에서 이용할 수 있는 자동 테스트 라이브러리이다. 이것과 VScode의 테스트 탐색기를 같이 이용한다면 테스트를 간편하게 진행할 수 있다."가 일단 내가 RSpec을 제대로 조사하기 전의 RSpec에 대한 생각이다. RSpec 사이트 에서는 "Behaviour Driven Development for Ruby. Making TDD Productive and Fun." (https://rspec.info/) 이라고 자신을 소개한다. TDD란 Test-Driven-Development라는, 일종의 프로그래밍 방법론이다. 자세한 것은 아래의 포스트를 참조. (TDD 개념 출처이다.) 간단하게 이야기하면, 개발을 진행하되 Test Code를 먼저 개발하며, 이를 통해서 원하는 기능을 만들고 피드백을 받는 것이다. 이 작업을 하는데 시간이 걸린다는 단점은 있지만, 다른 사람과 함께하는 협력적이면서도 불확실성이 큰 상황에서 쓰면 굿.

http://clipsoft.co.kr/wp/blog/tddtest-driven-development-%EB%B0%A9%EB%B2%95%EB%A1%A0/

 

TDD(Test-Driven-Development) 방법론 - CLIPSOFT

작성자 : 강성웅 부장   TDD(Test-Driven-Development) 방법론에 대하여…     - TDD가 무엇 일까? TDD란 Test Driven Development의 약자로 ‘테스트 주도 개발’이라고 한다. 테스트 주도 개발(TDD)은 설계 이후

clipsoft.co.kr

이론은 이쯤하고 실습을 해보자. 어떤 레인즈 컨트롤러가 제대로 동작하는지 테스트를 짜고 싶다면,

spec / controller / my_action_controller_spec.rb

RSpec.describe MyActionController, type: :controller do
	it "Test Case #1" do
		get :index, params: { args1: "blah blah", args2: "foobar" }
		expect(response).to have_http_status :success
	end
end

와 같이 지어 주면 짜주면 된다. RSpec을 그냥 일반 루비 클래스에서 만들어 본적이 없어서, 좀 더 낮은 레벨에서 코드를 분석하자.

 

describe는 테스트를 그룹화할때 쓰인다. 이게 또 보니까 얼마든지 nested 해서 쓸 수도 있다는 듯 한데,

describe "#index" do
	describe "menu" do
		it "menu click redirect works well" do
			# blah blah
		end
	end
end

이런 식으로도 가능. context도 사실 describe와 같은 역할을 수행하나, context는 일종의 조건이 있다는 것을 명시하기 위해서 쓰는 방식인 것 같다. 그래서 descirbe / descirbe 해서 쓰기 보다는 descirbe / context로 구별해주는게 읽기도 더 쉬우니, 그렇게 써야겠다.

 

Rails에서 특별히 type: :controller를 써주는 이유는, 아래의 controller 전용 테스트 메서드들을 이용하기 위해서 인듯 하다.

https://stackoverflow.com/questions/45023022/what-does-including-the-type-in-the-describe-block-of-a-rspec-do

 

What does including the type in the describe block of a rspec do?

I don't think the type part is necessary, what does it actually do? RSpec.describe Auction, :type => :model do

stackoverflow.com

그리고 get같은 특수한 전용 메서드들은 Rails API에서 확인해볼수 있다.

https://api.rubyonrails.org/classes/ActionController/TestCase/Behavior.html#method-i-get

 

ActionController::TestCase::Behavior

Namespace Methods B C D G generated_path, get H P patch, post, process, put Q S Included Modules Attributes [R] request [R] response Instance Public methods build_response(klass) Link Source: show | on GitHub def build_response(klass) klass.create end cont

api.rubyonrails.org

 

아무튼 이런 리소스를 이용해서 테스트를 짠다- 는 것 정도만 염두에 두면 기본적인 작성은 가능할 것 같다. 컨벤션이 어떻게 되는지는 따로 공부해야겠지만.

 

참조 :

https://choidacheeze.tistory.com/10

 

Rspec 기초

describe/ it / expect describe(RSpec.describe)는 테스트의 그룹화를 선언 번역하면 ~을 기술한다. ~을 설명한다 등의 의미 it은 테스트를 example단위로 정리하는 역할 it do ... end 의 expectation이 모두 패..

choidacheeze.tistory.com


https://www.betterment.com/engineering/guidelines-for-testing-rails-applications

 

Guidelines for Testing Rails Applications

Discusses the different responsibilities of model, request, and system specs, and other high level guidelines for writing specs using RSpec & Capybara.

www.betterment.com

이것에 따르면 Controller Spec 은 Rails 5.0+ 이후의 모던 레일즈에서 잘 사용하지 않는다고 한다. 대신 Request Spec을 이용하라고 하는데, 지금 작성한 내용을 그렇게 바꿔봐야 겠다.

728x90
반응형