내가 작성한 코드의 가장 작은 단위인 Method나 Function을 테스트하는 방법이다. 즉, 모든 메소드와 함수에 대한 테스트 케이스를 작성하는 절차를 말한다.
언제라도 코드 변경으로 인해 문제가 발생할 경우, 단시간 내에 이를 파악하고 바로 잡을 수 있도록 해준다.
배포 및 운영환경에서 정상 작동 여부를 자동화하여 테스트해볼 수 있다.
전체 테스트의 70%를 차지할 정도로 모든 테스트의 기반이다.
Google Test Automation Conference에서 제안된 테스트 피라미드로 아래 비중을 권장한다.
E2E(UI) Testing
- 10%Integrating Testing
- 20%Unit Testing
- 70%End-To-End Testing / UI Testing
브라우저 상에서 직접 테스트한다.
비용과 시간이 많이들고 부정확하다.
자동화가 까다롭다.
Integration Testing
최소 두개이상의 클래스 또는 서브 시스템의 결합을 테스트하는 방법
postman이나 httpie로 요청하고 응답을 확인하는 것
Unit Testing
가장 빠르고 정확하며 비용도 적게 든다.
유닛 테스트의 목적은 프로그램의 각 부분을 고립 시켜서 각각의 부분이 정확하게 동작하는지 확인하는 것이다.
즉, 프로그램을 작은 단위로 쪼개서 각 단위가 정확하게 동작하는지 검사하고 이를 통해 문제 발생 시 정확하게 어느 부분이 잘못되었는지를 재빨리 확인할 수 있게 해준다.
따라서 프로그램의 안정성이 높아진다. 유닛 테스트는 일견 개발 시간을 증가 시키는 것처럼 보이지만 개발 기간 중 대부분을 차지하는 디버깅 시간을 단축시킴으로써 여유로운 프로그래밍을 가능케 한다.
사후에 발견된 버그에 대해서도 버그를 수정한 후 유닛테스트를 작성해놓으면 앞으로 비슷한 사례에 대해서 버그를 방지할 수 있다.
새로운 기능을 구현할때 유닛 테스트를 잘 작성해놓으면 중장기적으로 유지 보수가 쉬워진다.
이전에 통과했던 테스트 집합을 가지고 버그를 찾기 위해서 이전에 테스트 되었던 유닛테스트를 반복하는것을 regression 테스트라고 하는데 유닛테스트만 반복하면 되기 때문에 regression 테스트도 반복적으로 수행 할 수 있다.
기존 코드가 어떤 기능을 하고 문제가 무엇인지 명확하게 파악할 수 있기 때문에, 새롭게 합류한 개발자를 위한 안내서로 활용될 수 있다.
유닛 테스트는 UI Test 또는 Integration Test 보다 테스트 비용이 저렴하다. 사람이 작업하고 눈으로 확인해야하는 과정이 없고 반복적으로 빠르게 테스트를 돌려볼 수 있다.
유닛 테스트는 다른 테스트에 비해서 실행 속도도 빠르다. 그래서 유닛테스트를 활용하면 하루에도 배포를 여러번 할 수 있어 개발 및 배포 속도에 중요한 영향을 주기 때문에 개발할 때 최대한 활용하는게 좋다.
테스트 유닛은 각 기능의 가장 작은 단위에 집중하여, 해당 기능이 정확히 동작하는지를 증명해야한다.
각 테스트 유닛은 반드시 독립적이어서 혼자서도 실행 가능해야하고, 테스트 슈트로도 실행 가능해야 한다. 이 때, 호출되는 순서와 무관하게 잘 동작해야하는데 새로운 데이터셋으로 각각의 테스트를 로딩해야 하고, 그 실행 결과는 꼭 삭제해야한다. ( setUp() 과 tearDown() )
테스트가 빠르게 돌 수 있도록 만들기 위해 노력해야한다. 무거운 테스트는 따로 분리하여 별도의 테스트 슈트를 만들어 두고 스케쥴 작업을 걸어둘 수 있으며 그 외의 다른 모든 테스트는 필요한 만큼 자주 수행하면된다.
지금 사용하고 있는 툴이 개별 테스트나 테스트 케이스를 어떻게 수행하는지 파악해야한다. 모듈 안에 들어있는 함수를 개발하고 있다면, 그 함수의 테스트를 자주, 가능하다면 코드를 저장할 때마다 자동으로 돌려야한다.
그날의 코딩을 시작하기 전후로 항상 풀 테스트 슈트를 돌려야한다. 특히 저장소에 올려 코드를 공유한다면 자동으로 모든 테스트를 수행하도록 하는 훅을 구현하는 하는 것이 좋다.
코드를 디버깅할 때 가장 먼저 시작할 일은 버그를 찝어내는 새로운 테스트를 작성하는 것이다.
테스트 함수에는 길고 서술적인 이름을 사용해 테스트 결과를 명확하게 알수있게 한다.