TIL#86 Unit Test

Testing Pyramid

Google Test Automation Conference 에서 제안된 테스트 피라미드이다. UI Testing은 10%, Integrating Testing은 20%, Unit Testing을 70%로 구현하는 것이 권장된다.

UI Testing / End-To-End Testing
크롬 브라우저를 띄운 뒤 직접 만든 검색페이지로 들어가서 검색을 해보고 제대로 나오는지 화면상에서 확인하거나, 직접 회원가입을 해보고 가입 후에 로그인이 되는지 직접 브라우저 상에서 값을 입력해서 테스트하는 방법이다. 가장 어렵고 까다롭다. 자동화할 수 있지만 가장 까다롭고 실행하기도 어렵다.

Integration Testing
최소 두개 이상의 클래스 또는 서브 시스템의 결합을 테스트하는 방법이다. ex) 장고로 runserver를 띄우고 모델클래스와 결합하여 데이터베이스 시스템과 연동한 테스트
Postman 또는 httpie로 호출해서 Json response가 제대로 출력되는지 확인하는 방법이다. UI Testing 다음으로 까다롭다.

Unit Test

작성한 코드의 가장 작은 단위인 함수를 테스트하는 메소드이다. 작성한 로직을 테스트하는 유닛테스트 코드를 짜서 테스트한다.

• 사람이 스크립트로 한꺼번에 자동으로 실행하기 때문에 UI Test 또는 Integration Test 보다 테스트 비용이 싸다.
• 다른 테스트에 비해 실행 속도가 매우 빠르다. 유닛테스트를 활용하면 하루에도 배포를 여러번 할 수 있어 개발 및 배포 속도에 중요한 영향을 준다. 최대한 활용하는 게 좋다.
• 새로운 기능을 구현할 때 유닛테스트를 잘 작성해 놓으면 중장기적으로 유지 보수가 쉬워진다.
• 유닛테스트를 잘 짜놓으면 유닛테스트가 되었던 코드에서는 버그가 거의 발견되지 않는다. 사후에 발견된 버그에 대해서도 버그를 수정한 후 유닛테스트를 작성해놓으면 버그를 방지할 수 있다.

Unit Test 의 일반 원칙

• 각 기능의 가장 작은 단위에 집중하여 해당 기능이 정확히 동작하는지를 증명한다.
• 각 테스트 유닛은 반드시 독립적이어야 한다. 각 테스트는 혼자서도 실행 가능해야하고 테스트 슈트로도 실행 가능해야 한다. 호출되는 순서와 무관하게 잘 동작해야 한다.
• 테스트가 빠르게 돌 수 있도록 만들기 위해 노력해야 한다. 무거운 테스트는 따로 분리하여 별도의 테스트 슈트를 만들어 두고 스케줄 작업을 걸어둔다. 그 외의 다른 모든 테스트는 필요한 만큼 자주 수행하면 된다.
• 그날의 코딩을 시작하기 전과 끝난 후에 풀 테스트 슈트를 돌려준다.
• 테스트 함수에는 길고 서술적인 이름을 사용한다. 테스트 함수는 절대 직접 호출되지 않기 때문에 가능한 한 서술적인 이름을 붙여야 한다. 함수명들은 테스트가 실패할 때나 보인다.