단위 테스트
단위 테스트
단위 테스트가 코드의 정확성을 확인하는 테스트인가? or 단위 기능에 관한 테스트인가?를 명확하게 하기
단위 테스트에는 엄밀한 정의가 없음
애매한 용어이며, 항상 논란이 됨
단위 테스트는 매우 어려움
코드를 처음부터 작성하는것이 아닌 이상 레거시 코드에서 테스트를 작성하는건 매우 어렵다!
코드를 커버하고, 단위 기능을 테스트하는 것은 개발자의 책임
테스트로 얻을 수 있는 포상
단위 테스트 케이스가 충분하므로, 이슈가 발생하면 즉시 문제를 알 수 있다.
리팩터링으로 다른 사람이 작성한 코드가 작동하지 않게 되더라도, 짧은 사이클로 버그가 침투해도 빠르게 발견할 수 있다.
"테스트를 가장 먼저 작성하는 것은, 소프트웨어를 릴리즈하기 쉬운 형태로 설계하는 상황으로 이어진다." - 로버트 마틴
코드 기반 단위 테스트
함수의 커버리지 비율을 측정해 로직의 확실성을 확인하는 화이트 박스 테스트
대부분의 버그를 발견할 수 있는 테스트 방법
"프로그래밍과 테스트를 동시에 수행하는 편이, 프로그래밍만 하는 것보다 빠르게 소프트웨어 개발을 완성할 수 있다." - 켄트 백
테스트 항목
입력값의 패턴을 100% 커버하고, 그에 대한 기대 처리가 올바른지를 체크하는 것
프로그램을 실행하는 도중, 시스템상의 이상 작동을 수행하지 않음
null pointer, 0으로 나누는 계산 등
입력값과 그에 대응하는 기댓값 출력
모든 분기가 올바르게 처리되는지 확인 (경곗값 테스트)
함수가 그 책임과 의무를 달성하는지도 동시에 주의할 것
단위 수준에서의 처리 기능의 버그를 없애는 것
기대 결과를 확인하지 않고 단순히 코드가 실행됐다는 것만으로 만족하면 안 된다. 즉, 단순히 커버리지를 높이기 위해 입력값을 넣는 것은 의미 없는 테스트다.
테스트 커버리지
베이스 코드가 테스트된 비율을 측정하는 지표
"커버리지만 신경쓰면 된다" 는 잘못된 사고방식
낮은 코드 커버리지는 넓은 코드 영역이 테스트되어 있지 않음을 보증한다.
높은 코드 커버리지라고 해서 반드시 품질이 높은것은 아니다.
자주 변경되는 코드는 커버해야 한다.
레거시 코드의 커버리지 비율을 방치해도 문제는 없지만, 조금씩 비율을 높여가는 것이 좋다.
명령 커버리지
코드의 실행 가능한 명령문이 최소 한번은 실행되었는지 확인하는 테스트 커버리지
if자체는 명령문이 아니라,{ }안의 실행 코드만 명령문으로 봄크게 의미 있는 테스트는 아님
극단적으로 표현할 경우 전혀 도움이 되지 않는다고도 함
모든 조건문이 올바르게 처리되었는지(경곗값 테스트) 측정할 수 없어서
어중간한 명령 커버리지 대신 확실한 조건 커버리지를 달성할 것을 권장
const isPositive = (a: number): boolean => {
if (a > 0) {
return true
}
return false
}
// isPositive(5)로 넣은 경우 5를 넣은 케이스의 한해서 모든 명령문이 실행됨을 체크하는 것조건 커버리지
각 조건식의 모든 개별 조건들이
true와false인 결과를 적어도 한 번씩 가지는지 확인하는 테스트 커버리지
명령 커버리지의 문제를 해결하는 커버리지 기법
모든 분기가 실행되었는지를 보장하지는 않음
const isValid = (a: number, b: number): boolean => {
if (a > 0 && b > 0) {
return true
}
return false
}
// isValid(1, 1), true true
// isValid(0, 1), false true
// isValid(1, 0), true false
// ----coverage 100%
// isValid(0, 0), false false 테스트 케이스를 작성하지 않아도 커버리지는 충족되는 허점 존재분기 커버리지
모든 분기(조건문)가 실행되었는지 체크
조건 내부의 각각의 평가값(
true/false)를 신경쓰지 않음복합 조건(
&&,||)이 있는 경우, 일부 조건이 특정 값만 수행되어 충족할 수 있음그래서 보통 조건 커버리지 + 분기 커버리지를 함께 고려해야 함!
const isValid = (a: number, b: number): boolean => {
if (a > 0 && b > 0) {
return true
}
return false
}
// isValid(0, 0)
// isValid(1, 1)
// ----coverage 100%
// 조건 a > 0와 b > 0가 true, false를 모두 수행했는지는 알 수 없음기능 단위별 단위 테스트
UI에서 기능(특히 복잡한 기능) 단위로 단위 테스트를 수행
기본적으로 블랙박스 테스트
일반적으로 UI로 부터 무언가를 입력하고 기댓값이 표시되는지를 확인하는 것
기능 단위의 단위 테스트 방법의 기본 요소
단위 기능 경곗값
조합
단위 기능 경곗값
각 기능이 처리할 수 있는 입력값의 경계를 테스트하는 방식
주로 입력값의 최소값, 최대값, 그 근처 값을 사용하여 시스템이 정상적으로 작동하는지 체크
조합
여러 입력값들의 가능한 모든 조합을 테스트하는 방식
반드시 해당 조합에서 버그가 발생하기 쉬운가를 생각하자.
이를 고려하지 않으면 필요한 테스트 케이스 수가 기하급수적으로 늘어남
먼저 데이터가 1 과 2 일 때 확실하게 커버하고, n 이라는 테스트 케이스를 적절한 개수로 한정해 작성할 수 있으면 품질 측면에서는 거의 문제가 없다고 봄
개발자가 생각지도 못한 방식으로 조합해서 버그가 발생하는건 포기하고 발생할 때 마다 케이스를 추가하자.
기능 단위별 단위 테스트에서 조합의 버그 검출 정확도는 현저히 낮다는걸 명심
블랙박스 테스트 vs 화이트박스 테스트
블랙박스 테스트로 모든 버그를 발견할 수 있다면, 더 큰 비용이 드는 화이트박스 테스트를 수행할 필요는 없다
화이트박스 테스트를 생략하면 일부 버그가 남게되는데 그 정도가 경미한 버그라면 문제 없다.
Last updated