> about System Test
System test는 기본적으로 구현한 로직이 의도한대로 실행되는지를
확인하는 과정을 말합니다.
예를 들면 회원 가입이 되는 경우를 테스트하고, 반대로 회원가입이 실패하는
경우를 테스트하기도 하며 일부러 정상적이지 않은 경우를 테스트해 보기도 합니다.
또한 이 과정에서 예상치 못해 예외처리를 하지 못한 에러를 발견하기도 합니다.
▶︎ Test Pyramid
Google Test Automation Conference에서는 다음과 같이
System Test의 종류와 비중을 피라미드 형식으로 표현하였습니다.
▶︎ System Test들의 특징
- UI Test(End-To-End Test)
Test Pyramid에서 UI Test의 비중은 10%입니다.
가장 어렵고 까다로운 테스트로 브라우저에서 로그인, 검색 등의 시스템을
하나하나 입력해가며 직접 테스트해야 하는 방법입니다.
프로젝트 시 API연결이 잘 되는지 FE와 통신테스트를 할 때 FE 개발자분이
로그인 창이나 필터를 일일이 작성하거나 클릭해서 확인하던 작업이 생각납니다.
UI Test의 자동화는 가능하지만 쉽지 않고 실행하기도 어렵습니다.
테스트피라미드의 비중에 따르면 자동화는 가성비가 상당히 떨어져 보입니다.
- Integration Test
Test Pyramid에서 Integration Test의 비중은 20%입니다.
BE 포지션에서 Postman 등으로 API 호출이 잘 되는지 테스트하는 과정과 같습니다.
따라서 최소한 API서버를 켜고 DataBase와 연동이 되어있는 조건이어야 합니다.
UI Test보다 비중은 두배 높지만 역시나 테스트 과정이 다소 번거롭습니다.
- Unit Test
Test Pyramid에서 Integration Test의 비중은 무려 70%입니다.
세팅은 필요하지만 DataBase에 Data가 입력되어있을 필요가 없고 Test 단위를 쪼개서
수십가지의 상황을 쉽게 재사용하고 시뮬레이션 할 수 있습니다.
보통 가장 쉽고 효과가 좋다고 알려져있는데 준비과정이 있기 때문에 규모가
아주 작은 테스트에서는 크게 체감할 수 없는 것 같습니다.
하지만 다양한 테스트를 해야할 경우 어느정도의 틀을 구축해 놓은 후에는
연관된 테스트들을 쉽게 작성할 수 있기 때문에 상황은 달라집니다.
> Unit Test
▶︎ Unit Test란
작성한 로직이 의도한대로 실행되는지를 작은 단위로 쪼개어 테스트하는 것을
Unit Test라고 합니다.
Postman으로도 할 수 있지만 하나씩 실행해보려면 시간이 오래 걸리며
DataBase서버가 구동되고 있어야 하기 때문에 좀 귀찮고 메모리 사용에 대한
비용면에서도 Unit Test보다 비싸다고 합니다.
이에 반해 Unit Test는 코드를 한 번 작성해두면 실행 한번에 다시 모든
테스트를 순식간에 끝낼 수 있으며 DataBase를 구동할 필요도 없습니다.
처음엔 낮설고 번거롭지만 이해가 되고 익숙해지면 편리한 도구입니다!
▶︎ 왜 Unit Test의 비중이 높을까
UI Test와 Integation Test는 모두 사람이 직접 테스트해야하는데 반해
Unit Test는 한 번 만들어놓은 Script를 그저 실행시키면 그만입니다.
Script를 작성해 놓는데는 물론 시간이 걸리지만 이후 테스트는 빠르게 수행 가능하며
해당 프로젝트 진행 중간이나 배포 후에 참여하는 사람은 해당 Test Script를 통해
Test와 관련된 로직을 이해하는데 도움이 되기도 하고 테스트와 관련된 시간이
추가적으로 소요되지 않기도 합니다.
이것은 중장기적 유지보수의 수월함과도 관련됩니다.
Unit Test가 잘 만들어져 있다면 해당 로직에서는 버그가 거의 발생하지 않으며
따라서 어떤 버그가 발생했다면 기존 완료된 Test들의 경우는 배제한 상황들에 대해
버그를 찾고 다시 테스트코드를 작성해두면 더욱 단단한 Unit Test를 구축할 수 있습니다.
▶︎ Unit Test 원칙
- 각 기능의 가장 작은 단위에 대해 테스트해야 합니다.
전체 로직을 한번에 테스트하는 것이 아닌 가장 작은 단위로 쪼개서 테스트를 만듭니다.
예를 들어 하나의 로직에 검색과 필터가 공존한다면 각각의 테스트를 별개의 함수로
테스트 코드를 작성합니다.
- 각 테스트 유닛은 반드시 독립적이어야 합니다.
개별 테스트들이 호출될 때 순서에 구애받지 않으며 단독으로 테스트가 가능해야 합니다.
setUp(), tearDown() 메소드를 통해 새로운 DataSet으로 각각의 테스트를
로딩하고 실행결과를 삭제합니다.
- 테스트가 빠르게 돌 수 있도록 만들기 위해 노력해야 합니다.
상황이 여의치 않을 때는 무거운 테스트는 따로 작성하여 관리하도록 합니다.
- 새로 코딩을 시작하기 전에 항상 풀 테스트 슈트를 돌려야 합니다.
기존의 코드가 문제가 없는지 확인하는 기점을 만드는 것이 어떤 문제가 발생했을 때
발생 시점이 새로 작성한 코드로부터인지 기존 코드로부터인지 판단하는데 유익합니다.
- 공유 저장소에 코드를 넣기 전 자동으로 테스트를 수행토록 하는 훅을 구현하면 좋습니다.
- 디버깅할 때 가장 먼저 할 일은 버그를 찝어내는 새로운 테스트를 작성하는 것입니다.
버그잡이 테스트는 프로젝트에서 가장 가치있는 코드조각이 됩니다.
- 테스트 함수에는 길고 서술적인 이름을 사용하셔야 합니다.
테스트 결과가 실패일 경우 해당 함수 이름으로 식별할 수 있기도 하며
해당 테스트가 어떤 의도인지 쉽게 파악할 수 있기 때문에 서술적인 함수명이 옳습니다.
- 좋은 테스트 셋을 만들어 놓아야 합니다.
오류를 수정하거나 프로그램의 동작을 수정하는 관련자들은 잘 만들어진 테스트 슈트에
전적으로 의지할 것입니다.
- 새로운 개발자들을 위한 안내서로 쓰입니다.
테스트 코드를 돌려보면 어느 지점이 문제인지, 수정하기 어려운 곳은 어디일지,
막다른 골목은 어디일지를 발견하게 됩니다.
또한 새로운 기능을 추가해야 한다면 가장 먼저 해야할 일은, 그 새로운 기능이
아직 돌아가지 않음을 확인할 수 있는 테스트를 붙여넣는 것입니다.
> 참고자료 / 이미지 출처
▶︎ What is Testing Pyramid?
