이전에는 API를 작성하고 테스트할 때,
zshell, Postman을 이용해서 내가 원하는 값이 출력되는지 확인하고 디버깅했다.
이번 2차 프로젝트부터는 Unit Test를 추가하기로 했다.
Unit Test?
한 번의 실행으로 작성한 함수를 테스트하는 메소드
기능이 추가, 제거되거나 변경되었을때,
일련의 모든 테스트를 직접해보는 것은 시간, 비용면에서 큰 loss이다.
테스트 코드를 작성할 경우, 리팩토링하는 시간을 크게 줄여줄 수 있으며
해당 코드를 처음 보는 사람은 코드가 어떤 목적을 가지고 어떻게 동작하는지
알아볼 수 있다.
또한 중장기적인 측면에서 유지보수에 용이하다.
테스트 코드를 작성하는 5가지 규칙 FIRST
F: Fast
테스트 코드가 느릴 경우, 자주 돌려보기 어렵다.
I : Independant / Isolated
각 테스트가 다른 테스트에 영향을 끼쳐서는 안된다.
R : Repeatable
어떠한 환경에서도 반복적으로 돌릴 수 있어야 한다.
S : Self-Validating
Boolean 값으로 결과를 나타내야한다.
T : Thorough / Timely
실제 코드를 구현하기 직전에 작성한다.
기능 목표의 커버리지를 명확하게 알기위해 철저하게 작성한다.
테스트 코드의 구성요소 (Django)
setUp : 모델링을 기본으로 가상 DB에 Data를 만드는 단계이다.
Migration 파일을 기반으로 DB가 구축된다.
tearDown : 테스트가 끝나고 setUp 단계로 가기 전, 수행되는 단계이다. 기본적으로 등록해놓은 데이터를 모두 삭제한다.
Test : 테스트명은 최대한 자세하게 작성한다.
다른 사람이 보고 어떤 목적을 가진 테스트인지 인지할 수 있어야한다.
assertEqual를 이용해서 response된 값이 테스트 목적에 맞는 response와 동일한지 boolean으로 표시한다.
개인적으로 유닛 테스트를 접했을 때, 알고리즘 문제를 떠올렸다.
우선 내가 원하는 기능이 구현되고, 리팩토링하면서 효율성을 높이는 과정이
비슷하다고 생각했다.
2차 프로젝트가 끝나고 1차 프로젝트에 작성했던 코드를
유닛 테스트해보는 것도 좋은 공부 방법이 되겠다.
