Why Testing?
- 더 나은 코드
- 나은 계획수립 가능
- 테스트 더 할 수 있음
- 버그 감소 (빨리 잡을 수 있음 / regression)
- code coverage 증진
Unit Testing
개념
-
Automated Testing (자동화 테스팅)
1-1. 함수, 클래스 및 개념적 묶음의 최소 단위로 테스팅
1-2. 처음에 직접 테스팅이 가능하나, 프로젝트의 규모가 커질수록 시간 및 복잡도에 의해 불가능
1-3. Unit Test 를 작성하면 Automation 가능
1-4. Test Runner 가 알아서 test 찾기/실행/성공여부 판단
-
Regression Testing (회귀 테스팅)
이전에 잘 되던게 안되는 버그 (Regression Error) 을 대응하기 위한 테스트
Unit test 작성 가이드라인
- 독립적으로 동작되어야하며, 종속성 이 없어야함
- 작동 속도가 빨라야함 (1 유닛 당 크기 제한)
- 외부 인풋 (네트워킹, 마우스, 키보드 등) 에 종속되면 안됨
Unit test 구조
3A (AAA)
Arrange
Act
- 테스트할 Unit execute (method, class ...)
Assert
이 구조의 장점?
분리 (Separation) - 무엇을 테스트 할 것 인가? - 셋업 & 검증
Code smells: more obvious
Which Testing?
White-box or Glass-box testing (코드만을 평가)
-
Unit Testing
- 코드 단위의 함수나 클래스 및 개념적 묶음을 최소 단위로 테스팅
- Isolated
-
Integration Testing
- Unit 의 모듈 단위로 테스트 (code modules, individual apps, client-server apps ...)
black-box testing (내부 코드의 개입이 없는 순수 동작만을 평가)
-
Functional Testing
-
System testing / End-to-End (E2E) testing
- 실제 서버에 올려서 테스트
- 마우스, 키보드 및 기타 Browser Input 단위로 테스팅
= 실제 최종 사용자 (유저) 의 동작을 테스팅
- Cypress, Selenium
-
Load testing
- SW 를 가혹한 환경에서 테스트 (heavy traffic, attack ...)
-
Acceptance testing
- SW 가 user-friendly 여부 테스트
Unit Testing vs Functional Testing
마인드셋이 다름! (접근법)
Unit Testing
- Isolated: mock 에 종속됨, internal test
- 어떤 것을 테스트 해야할 지 정하는게 어려움 (+)
- 유저의 실제사용과 관련이 없을 수 있음 (-)
- 리팩토링에 취약함 (-)
Functional Testing
- 모든 관련된 test 포함, 최종 사용자의 interact 를 test
- test 크기가 큼, 커버리지가 큼 (+)
- debug 하기 어려움 (코드가 coupling 되어 있어서) (-)