- Why Test? : 우리가 개발한 것 확인 가능. 모듈들이 결합해서 동작상에 버그가 없는 것을 확인하기 위해 필요
- 시스템 테스트 방법 3가지(Testing Pyramid)
(1) E2E(UI) Testing (10%)
(2) Integrating Testing (20%)
(3) Unit Testing (70%)
- 테스트는 버그가 있음을 보여줄 뿐, 버그가 없음을 보여줄 수는 없다. (by 에츠허르 비버 데이크스트라)
=> 모든 테스트가 모든 버그를 잡을 순 없지만, 테스트를 통해 최소한의 버그를 잡을 순 있다.
End-to-End test 또는 UI Test 라고 함
장점
단점
테스트 실행 속도 저하
: 예상하는 시나리오대로 인력이 투입되어 A부터 Z까지 모두 진행해야 함인력소모 커짐
: 테스트할 기능이 많다면 한 사람으로는 부족하므로 많은 사람이 투입되어야 하고 그에 따라 인력이 소모 됨테스트의 불안정성 커짐
: 테스트 자체도 사람이 하는 일이다 보니 놓칠 수 있는 부분 발생비용 증가
: 속도가 느리고 그만큼 시간 투자 및 인력투자가 필요
- Google Test Automation Conference 에서 제안된 테스트 피라미드
- 전체 테스트 비중을 아래와 같은 수치로 구현하는 것이 권장됨
(1) End-To-End Testing (UI Testing) - 10%
(2) Integrating Testing - 20%
(3) Unit Testing - 70%
위 3가지 테스트 모두 사람이 직접 눌러서 테스트 하는 것이 아닌, 코드로 코드를 테스트 하는 것임
테스트 단위가 좀 더 쪼개질수록 어느 부분에서 에러가 발행했는지 좀 더 찾기가 쉬워짐
End-To-End Testing
보다는 Integrating Testing
에 테스트 비중을 좀 더 많이 가져가야 하고Integrating Testing
보다 더 쪼개진 단위인 Unit Testing
에 테스트 비중을 좀 더 많이 가져가야 함
- 크롬 브라우저를 띄운 다음, 내가 만든 검색페이지로 들어가서 검색을 해보고 검색한 내용이 제대로 나오는지 화면상에서 확인하거나 직접 회원가입을 해보고 회원가입후에 로그인 되는지 직접 브라우저 상에서 값을 입력해서 테스트 하는방법
- UI Testing이 가장 어렵고 까다로움
- Manual Testing은 실행하기 쉽다는 장점이 있지만 비용이 많이 들고 부정확하며 실행 시간이 오래 걸림
- 자동화 할 수 있지만 UI Testing은 자동화 하기가 가장 까다롭고 또 실행하기도 까다로움
프론트엔드와 백엔드 모두 코드가 완성된 상태에서 진행하는 test
사람이 테스트할 기능들을 모두 직접 실행하는 테스트가 아닌, 그 시나리오를 코드로 짜는 것
이런 테스트는 주로 프론트엔드 단에서 많이 함
- 최소 두 개 이상의 클래스 또는 서브 시스템의 결합을 테스트하는 방법
- (ex) 장고로 서버를 띄우고 모델 클래스와 결합하여 데이터베이스 시스템과 연동한 테스트
Postman
또는httpie
로 호출해서 Json response가 제대로 출력되는지 확인
- Integration Testing이 E2E Testing 다음으로 공수가 많이 듬
내가 client인 척(프론트엔드)하면서 백엔드 서버에 요청을 보내고, 그 요청에 대한 응답을 보낼 수 있는 테스트
프론트엔드 및 백엔드 각각 분리된 서버를 통해 각각 테스트 하는 것
장점
- code로 code를 테스트
- Unit Testing이 가장 쉬우며 효과가 좋음
- 빠르고 비용이 싸므로 개발할 때 필수적으로 작성해야 함
What is Unit Test?
테스트 할 수 있는 가장 작은 단위
를 테스트 하는 코드를 작성하여 테스트 하는 것함수
또는 메소드
를 테스트하게 됨Testing 라이브러리
jest
(가장 많이 사용), enzymeunittest
(장고에서 기본적으로 사용)[참고] Python Unit Test 개념 및 용어
TestCase
: 어떤 함수를 테스트 할 것인지가 있어야 함Fixture
: 테스트를 진행할 때는 실제 데이터를 가지고 테스트 하지 않음. 이 테스트를 진행하기 위한 데이터를 만들어 줘야 하는데 그것을 Fixture 라 함assertion
: Unit Test 를 실행하면서 assertion 부분에서 내가 테스트 한 것이 맞는지 여부를 판단하게 됨Unit Test 는 이미 우리가 작성한 코드가 정해져 있고, input 과 output 을 미리 결정 함
보통 Unit Test 를 할 때는 3가지를 진행
'1'[참]
'-1'[거짓]
'0'[예외처리]
테스트 유닛은 각 기능의 가장 작은 단위(ex. 함수, 메소드)에 집중
각 테스트 유닛은 반드시 독립적이어야 함
테스트가 빠르게 동작할 수 있도록 만들기 위해 노력
< 참고 >
- CI는
Continuous Integration
즉, 지속적인 통합이라는 의미
지속적인 통합
이란, 어플리케이션의 새로운 코드 변경 사항이 정기적으로 빌드 및 테스트 되어 공유 repository에 통합하는 것을 의미(가능하다면 하루에 여러번까지)
< 참고 >
- CD는
Continuous Delivery
혹은Continuous Depolyment
두 용어 모두의 축약어
지속적인 서비스 제공
혹은지속적인 배포
라는 의미
Continuous Delivery
는 공유 repository로 자동으로 Release 하는 것을 의미
Continuous Deployment
는 Production 레벨까지 자동으로 deploy 하는 것을 의미
< 참고 >
- 즉,
CI
는 새로운 소스코드의 빌드, 테스트, 병합까지를 의미
CD
는 개발자의 변경 사항이 repository를 넘어, 고객의 프로덕션(Production) 환경까지 Release 되는 것을 의미
지금 사용하고 있는 툴에 대해 개별 테스트나 테스트 케이스를 어떻게 수행하는지 배워야 함
그 날의 코딩을 시작하기 전에 항상 풀 테스트 슈트를 돌려야 함
모두가 공유하는 저장소(ex. Github)에 코드를 merge 하기 전에 자동으로 모든 테스트를 수행하도록 하는 훅을 구현하는 것이 좋음
코드를 디버깅할 때 가장 먼저 시작할 일은 버그를 찝어내는 새로운 테스트를 작성하는 것
테스트 함수에는 길고 서술적인 이름을 사용해야 함
테스트 코드의 또다른 사용 방법은 새로운 개발자들을 위한 안내서로 쓰는 방법임
<출처> wecode(코딩 부트캠프) 세션