테스트 가능한 가장 작은 단위의 모듈을 실행하여 올바른 결과물이 출력되는 지 확인하는 테스트이다. 일반적으로 클래스 또는 메서드 단위로 실행하며 단위가 작을수록 복잡성이 낮아진다. 자신이 작성한 코드에 대해 테스트 코드를 작성하며 구현된 코드의 내용을 알고 있어야 하는 화이트 박스 테스트이다.
단위 테스트보다 더 큰 단위의 동작을 확인하기 위한 테스트로, 최소 두 개 이상의 서브 시스템을 결합하여 테스트하는 것을 말한다.
postman이나 httpie를 이용하여 장고 서버와 DB서버가 정상적으로 통신하고 올바른 결과물을 출력하는지 확인하는 것을 예로 들 수 있다.
단위 테스트보다 더 많은 코드를 실행하기 때문에 에러가 어디서 발생했는지 파악하거나 수정하는 것이 비교적 어렵다.
결과물을 사용자 시점으로 시나리오에 맞춰 테스트하고 예상되는 결과가 나오는지 확인하는 테스트이다. 가령 상품 조회 페이지로 들어가서 원하는 데이터 값이 나오는지 또는 회원 가입이 정상적으로 동작하는지 등을 확인하는 것이다. 백엔드 관점에서는 실제 서버에 요청을 보내고 클라이언트로 원하는 데이터가 보내졌는지 확인한다.
테스트 중 가장 까다롭고 비용이 많이 드는 테스트이다.
Google Test Automation Conference에서 제안된 Testing pyramid에 따르면 전체 테스트의 비율은 E2E Test 10%, Intergration Test 20%, Unit Test 70%
를 유지하는 것이 이상적이라고 한다.
단위 테스트의 장점이 무엇이길래 중요성이 강조되는걸까?
가장 큰 이유는 테스팅에 소요되는 비용을 들 수가 있다.
통합 테스트, E2E테스트 같은 경우 테스트를 위해 다른 시스템과 반드시 결합되어야 한다. 결합되어야하는 요소들이 많을 수록 테스트 환경을 준비하는데에만 소요되는 시간이 꽤 오래 걸릴 것이다. 하지만 단위 테스트는 필요 모듈만 부분적이고 독립적으로 테스트를 실행하여 빠른 테스트가 가능하며 다른 테스트에 비해 실행 속도 자체도 빠르기 때문에 잦은 수정과 배포가 가능하다.
잘 작성된 테스트 코드는 중장기적으로 유지보수를 용이하게 해준다. 이전에 통과된 단위 테스트를 반복 실행하여 버그를 찾는 regression 테스트를 할 수 있으며 리팩토링시에도 테스트 코드까지 수정하는 것이 아니라 이전 테스트를 실행하며 테스트를 통과하는지 확인해주기만 하면 된다.
또한 high-level 테스트에서 버그가 발생했다는 것은 코드 상에 문제가 있다는 것외에도 단위 테스트의 부재 또는 테스트가 잘못 작성되었음을 의미한다. 따라서 올바른 단위 테스트를 작성하고 반복 실행하므로써 버그를 최소화하는 것이 좋다.
1개의 함수에 대해 assert를 최소화 해야하며 함수가 맡은 기능이 잘 동작하는지에 초점을 맞춰야한다.
단위 테스트는 실행 속도가 빠르고 비용이 적게들기 때문에 반복 실행할 수 있다는 장점이 있다. 따라서 테스트가 실행 될 때는 시간이 너무 많이 소요되지 않도록 해야하며 어쩔 수 없이 시간이 많이 소요되는 테스트는 테스트 슈트를 분리하거나 스케쥴 작업을 걸어두는 것이 좋다.
지금까지 테스트의 종류와 단위 테스트의 중요성에 대해 알아보았다. 단위 테스트는 모듈이 잘 동작하는지 확인하는 것은 물론 미래의 후임 개발자가 코드를 이해하고 유지 보수를 하는 것을 쉽게 해주기도 한다. 따라서 나 뿐만이 아닌 팀의 작업에도 도움을 줄 수 있도록 유닛 테스트 작성 및 잦은 실행을 습관화하는 것이 좋다.