단위 테스트 (1) - 단위 테스트의 목표

단위 테스트 1장, 단위 테스트의 목표

Transcript

1. 단위 테스트 (1) 단위 테스트의 목표 2023.11 개발본부 유성은
2. 1. 단위 테스트 현황 2. 단위 테스트의 목표 3. 테스트 스위트 품질 측정을 위한 커버리지 지표 4. 무엇이 성공적인 테스트 스위트를 만드는가? 5. 이 스터디로 배울 것들 목차
3. 들어가며 이번 세미나에서 다룰 내용 • 주로…. – 효율적인 테스트 코드 짜기 – 최대한의 이득을 보는 테스트코드 설계하기 – 테스트에 대한 비용 편익 분석(cost-benefit analysis) 방법 익히기 – 테스트 안티패턴 피하기 • 부차적으로…. – 테스트 프레임워크 다루기 – 목(mocking) 라이브러리 다루기
4. 1.1 단위 테스트 현황 • (책 출시가 2021년 4/4분기) 20년 전 부터…. – 테스트코드의 중요성이 대두되었음 – 엔터프라이즈 앱 [1] 의 제품 코드와 테스트코드의 비율은 1:1, 1:3, 많으면 1:10까지 – 좋은 테스트코드를 짜야 한다는 건 알겠는데, “좋은” 테스트가 뭐지? • 좋은 테스트란…. – 투자 대비 성능이 좋은 테스트 – 이상적인 테스트 vs 실용적인 테스트 [1]: 높은 비즈니스 복잡도, 긴 프로젝트 수명, 중간 크기의 데이터, 낮은~중간정도 성능을 요구
5. 1.2 단위 테스트의 목표 • 단위 테스트를 하면 얻는 점 – 좋은 설계? – 소프트웨어의 지속 가능성 [1]: 열역학 제 2법칙의 그 엔트로피에서 이름을 따옴. 시스템 내의 무질서를 의미 [2]: 회귀(regression): 코드 수정 후 기능이 의도대로 작동하지 않는 경우. 즉, 버그. • 지속 가능성 – 소프트웨어 엔트로피 [1] 증가 속도를 완화시킴 – 엔트로피가 상승 → 코드 신뢰 하락 • 정리되지 않은 코드들 • 리팩터링하지 않은 코드들 • 한 부분이 수정되면 다른 부분이 고장나는 코드들 – 테스트는 엔트로피 역전(!)이 가능 – 테스트는 회귀(regression) [2] 에 대한 보험
6. 1.2 단위 테스트의 목표 (cont’d) • 잘못된 테스트코드? – 여전히 소프트웨어 엔트로피를 상승시킴 – 테스트를 위한 테스트로 전락 – 결국 일만 두 배가 됨 → 늦게 퇴근(중요) • 그렇다면? – 테스트의 가치-유지비용을 고려해야 함 • 코드베이스 리팩터링 시, 테스트도 리팩터링 • 코드 변경 시 테스트 실행 • 테스트가 잘못된 오류를 발생시키면 바로 처리하기 • 코드베이스의 스펙은 곧 테스트코드의 스펙 – 고품질의 테스트 ‘코드’ 관리하기 • 버그에 취약 • 유지보수 필요
7. 1.3 테스트 스위트 품질 측정을 위한 커버리지 지표 • 커버리지 지표 [1] – 수치가 낮은 건 부정 지표지만, 수치가 좋으면 좋다 – 높은 수치의 지표 값이 좋은 테스트 코드임을 보장하지는 않는다 [1]: 테스트 스위트가 소스코드를 얼마나 실행시키는지에 대한 백분율
8. 1.3 테스트 스위트 품질 측정을 위한 커버리지 지표 (cont’d) • 코드 커버리지 (aka. 테스트 커버리지) – 하나 이상의 테스트로 실행된 코드 라인 수와 제품 코드베이스의 전체 라인수의 비율
9. 코드로 봅시다.
10. 1.3 테스트 스위트 품질 측정을 위한 커버리지 지표 (cont’d) • 코드 커버리지 (aka. 테스트 커버리지) – 하나 이상의 테스트로 실행된 코드 라인 수와 제품 코드베이스의 전체 라인수의 비율 – 보고 온 코드로 ‘장난치는’ 게 가능 – 이렇게 코드 커버리지가 올라봐야 무의미
11. 1.3 테스트 스위트 품질 측정을 위한 커버리지 지표 (cont’d) • 분기 커버리지 – 하나 이상의 테스트가 통과하는 제어구조의 수 – 코드베이스의 모든 분기를 합산하고, 그 중 테스트가 얼마나 실행되었나 확인 – 해당 분기를 구현하기 위한 코드를 고려하지 않음
12. 1.3 테스트 스위트 품질 측정을 위한 커버리지 지표 (cont’d) • 커버리지 지표 비판 – 테스트 대상 시스템의 모든 가능한 결과를 검증한다고 보장하는 것이 아님 – 외부 라이브러리의 코드 경로를 고려할 수 있는 커버리지 지표는 없음
13. – 테스트 대상 시스템의 모든 가능한 결과를 검증한다고 보장하는 것이 아님 코드로 봅시다.
14. – 외부 라이브러리의 코드 경로를 고려할 수 있는 커버리지 지표는 없음 코드로 봅시다.
15. 1.3 테스트 스위트 품질 측정을 위한 커버리지 지표 (cont’d) • 커버리지 지표 비판 – 특정 커버리지 숫자를 목표로 하지 않기 – 병원에서, 환자의 체온은 건강의 지표 중 하나입니다. 그렇지만 독감 환자의 체온을 낮추기 위해 병실의 에어컨을 빵빵하게 트는 게 효율적 인가요?
16. 1.4 무엇이 성공적인 테스트 스위트를 만드는가? • 좋은 테스트 스위트의 특성? 1. 개발 주기에 통합되어 있음 2. 코드베이스에서 가장 중요한 부분을 테스트함 3. 최소한의 유지비로 최대의 가치를 이끌어냄
17. 1.4 무엇이 성공적인 테스트 스위트를 만드는가? (cont’d) • 개발 주기에 통합된 코드 – 자동화된 테스트는 끊임없이 돌리고, 개발주기에 통합시켜야 함
18. 1.4 무엇이 성공적인 테스트 스위트를 만드는가? (cont’d) • 코드베이스에서 가장 중요한 부분을 대상으로 함 – 시스템의 가장 중요한 부분에 단위 테스트 노력을 기울이기 – 다른 부분은 간략하게/간접적으로 검증하기 • 대부분의 앱에서 중요한 부분은 비즈니스 로직(도메인 모델) • 나머지 모든 부분은 아래 범주에 속함 (2부에서 추가설명) – 인프라 코드 – 외부 서비스 및 종속성(E.g., DB, 서드파티 시스템) – 모든 것을 하나로 묶는 코드 – 다만 상기 내용들은 코드베이스의 중요한부분/덜 중요한 부분으로 나누어야 함
19. 1.4 무엇이 성공적인 테스트 스위트를 만드는가? (cont’d) • 최소 유지비로 최대 가치를 끌어냄 – 가치 있는 테스트(그리고 쓸데없는 테스트) 식별하기 – 가치 있는 테스트 작성하기
20. 1.5 이 스터디로 배우는 것들 • 테스트 코드를 설명하기 위한 기준틀 설명 → 리팩터링 대상 및 제거코드 파악 완료 • 기존 테스트 기술과 실천방법 및 better case • 제품코드와 관련 스위트를 리팩터링 하는 방법 • 단위 테스트의 다양한 스타일 적용법 • 통합 테스트로 시스템 전체 동작 검증 • 단위 테스트의 안티패턴 식별 방법, 예방법
21. Q&A
22. 감사합니다