Two Scoops of Django - #22장

이번장은 테스트에 대한 내용이다.

테스트는 정말 중요한 거 같다. 특히 일의 효율성을 위해서는.

그리고 가끔은 내가 짠 코드를 내가 못 믿을 때도 있어서 사실 테스트는 무조건 필요한 거 같다.

 

1. 돈, 직장, 심지어 생명과도 연관되어 있는 테스팅 : 인간의 실수가 테스트 과정에 영향을 미칠 수 있으니 항상 유의할 것

 

2. 어떻게 테스트를 구축할 것인가 : 테스트 모듈은 test_ 접두어를 붙여 생성할 것

 

3. 단위 테스트 작성하기 : 최소한의 시간을 들여 가장 의미 있는 테스트 코드를 만드는 법 소개

 - 각 테스트 메서드는 테스트를 한 가지씩 수행해야 한다 : 그러나 방법론 자체에 문제가 있을 수 있다. 특별한 테스트에 대한 환경을 완전히 최소한으로 구성할 것
 - 뷰에 대해서는 가능하면 요청 팩토리를 이용 : 세션과 인증을 위한 미들웨어 지원을 위해서는 추가적인 작업이 필요

 - 테스트가 필요한 테스트 코드를 작성하지 말 것 : 테스트 케이스 안의 코드가 복잡하거나 추상적이지 않을 것

 - 같은 일을 반복하지 말라는 법칙은 테스트 케이스를 쓰는 데는 적용되지 않음 : 테스트의 경우 비슷한 코드를 여러 번 반복해서 또 써도 된다. 복붙 괜찮

 - 픽스처를 너무 신뢰하지 말 것 : 픽스처를 사용할 때 오히려 더 큰 문제를 일으킬 가능성도 있다. 프로젝트의 데이터가 바뀌면서 픽스처 자체도 변경될 수 있으며 최신 데이터 마이그레이션에 맞춰 JSON 포맷의 파일 수정 자체가 번거롭다. factory by, model mommy, mock 등의 서드 파트 패키지를 활용할 것

 - 테스트해야 할 대상들 : 전 부 다! 전부 테스트해야 함.

 - 테스트의 목적은 테스트의 실패를 찾는 데 있다 : 실패 시나리오는 언제나 발생 가능. 테스트가 통과했다고 모든 시나리오가 문제없을 거라는 생각은 하지 말 것

 - 목을 이용하여 실제 데이터에 문제를 일으키지 않고 단위 테스트 : 단위 테스트 자체를 통합 테스트로 변경하거나 목 라이브러리를 이용하여 외부 API에 대한 가짜 응답을 만들 것.

 - 좀 더 고급스러운 단언 메서드 사용 : 단순 assertEqual() 외에도 다른 단언 문 이용 가능.

 - 각 테스트의 목적을 문서화 : 각 클래스, 메서드, 함수에 대해 독 스트링을 이용하여 문서화하는 것처럼 테스트에 대한 목적과 분석을 문서화할 것.

 

4. 통합 테스트란 : 개별적인 소프트웨어 모듈이 하나의 그룹으로 조합되어 테스트되는 것을 의미. 단위 테스트가 끝난 후에 행하는 것이 가장 이상적. 

 - 애플리케이션이 브라우저에서 잘 동작하는지 확인하는 셀레늄 테스트

 - 서드 파티 API에 대한 가상의 목 응답을 대신하는 실제 테스팅.

 - 외부로 나가는 요청에 대한 유효성을 검사하기 위해 requestb.in이나 http://httpbin.org 등과 연동하는 경우

 - API가 기대하는 대로 잘 작동하는지 확인하기 위해 runscope.com을 이용하는 경우

통합 테스트는 모든 부분이 잘 작동하는지 확인하기 위한 훌륭한 방법. 그러나 문제점도 있음

 - 세팅에 많은 시간이 소요될 수 있음

 - 단위 테스트와 비교하면 테스트 속도가 느림.

 - 통합 테스트로부터 반환된 에러의 경우, 에러 이면에 숨어 있는 에러의 원인을 단위 테스트보다 찾기 어려움.

 - 단위 테스트에 비해 통합 테스트는 좀 더 많은 주의를 요구

 

5. 지속적 통합 : 어떤 크기의 프로젝트라도 저장소에 새로운 코드가 커밋될 때마다 테스트를 실행하는 지속적 통합 서버를 세팅하기를 추천

 

6. 알 게 뭐람? 테스트할 시간이 어디 있다고! : 이게 리얼 내맴이기도 함.. 사실 업무가 여러 개 몰려오다 보면 테스트는 생각도 안 하고 일단 코드부터 작성하게 됨 ㅠㅠ. 저자는 실력이 어느 정도 올랐을 때 테스트가 필요 없다고 생각하고 테스트 자체에 시간이 많이 걸린다고 생각할 수도 있다고 한다. 그러나 초기에 테스트를 추가함으로써 결국 많은 양의 일을 막을 수 있다.

 

7. 테스트 범위 게임 : 최대한 많은 범위의 테스트를 하는 게임을 해보길 바람. 날마다 테스트 범위가 넓어질 때마다 이기는 것이고 줄어들 때마다 지는 것

 

8. 테스트 범위 게임 세팅 : 다음의 단계를 따를 것을 요구

 - 1 단계 : 테스트 작성 시작

 - 2 단계 : 테스트 실행하기, 그리고 커버리지 리포트 작성

 - 3 단계 : 리포트 생성. htmlcov/에 index.html을 열면 테스트 실행으로 생성된 결과를 볼 수 있음.

 

9. 테스트 범위 게임 시작하기 : 테스트 커버리지를 낮추는 그 어떤 커밋도 허용하지 않을 것

 

10. unittest의 대안 : 물론 unittest가 강력하고 유용한 도구지만 선호하지 않는 사람도 있다. 그런 경우에는 다른 라이브러리를 이용해도 좋다.

 

테스트는 정말 중요하긴 한데.. 사실 나도 아직까지 테스트 지향적으로 일을 하고 있지는 못한 거 같다. ㅠㅠ
그래도 좀 더 신경 써서 진행해야지..