00pen.tistory.com/91

 

TDD를 해야 하는 이유 #1

최근에 사수님께서 "이제 00도 테스트코드를 짜면서 코드를 짜보세요." 라고 하셨다. 그래서 당연히 넵 :) 이라고 답했다. 근데 "테스트코드를 먼저 짜면서 코드를 작성해보세요" 라고 하셨다. 나

00pen.tistory.com

저번에 글을 쓸 때는 자신만만하게 '이렇게이렇게 해야한다!' 라고 말했지만 막상 만들어보려니까 assert문을 얼마나 넣어야할지 모르겠다는 생각이 들었다. 가장 작게 유닛테스트를 하는 것이 가장 기초이고, 유닛테스트부터 시작해봐야야 할 것 같다는 생각이 들었다.

 

먼저 가장 작게 하나의 함수나 메소드를 테스트하는 것이 가장 작은 유닛테스트가 될 것 같다. 기본적으로 내가 생각한 값이 나오는지 확인하고, 더 잘 확인하기 위해서는 어떤 범위가 나와야하는 함수라면 그 범위의 경계선도 체크하는 것도 중요하다고 알게 되었다.

 

그리고 최근에 Django를 이용해 api를 만드는 도중에 테스트 코드를 몇 개 짜봤는데 이런 프레임워크 안에는 단순히 python의 unittest를 사용하기엔 어려움이 있는 것 같고, 프레임워크 안에 test를 위해 만들어진 module이 있다면 그걸 사용하는 것이 맞는 것 같다. 왜냐하면 Django를 보았을 때 response를 테스트를 해야하는 것이 많은데 이걸 테스트하기 위해서 unittest를 쓰는 건 불가능하진 않지만 비효율적이고, django 또는 django rest framework 안의 test를 이용해야 client나 factory 이런 걸 활용해야 효율적으로 test 코드를 만들 수 있기 때문이다. 아래는 django, DRF의 test 코드 예시이다.

developer.mozilla.org/ko/docs/Learn/Server-side/Django/Testing

www.django-rest-framework.org/api-guide/testing/

 

이렇게 말하고 있지만 뭘 만드는데 완벽하게 유닛테스트 코드를 짜고, 만들기엔 그렇게 큰 프로젝트를 맡고 있지 않기 때문에 간단하게 한 class에 대해 setuplcass, teardownclass 넣고, 그 다음 모든 method에 대해 하나 또는 소수의 assert문만 넣어 끝까지 오류 없이 돌아가는지 정도만 test를 하고 있다.

근데 사실 절대 버그가 생기면 안되거나 여러 곳에서 참조하는 모듈이 아니라면 완벽하게 unittest를 다 만들고 하는 하는 것보다 빠르게 ( 그리고 잘 ) 만들고 오류가 난다면 바로바로 고쳐주는 게 더 효율적이라고 생각한다...

+ Recent posts