11/23 TIL | 테스트 고치기!

이번 강의에서 처음 작성했던 테스트들을 통과시키기 위해 테스트를 고치셨다. 테스트를 통과시키는 것도 중요하지만 테스트 자체를 고치는 것도 필요하다. 근데 '테스트를 통과 못하니까 테스트를 고쳐야지'라는 말은 사실 논리적으로 맞지가 않는다.. 마치 시험을 보는데 시험 문제를 틀리니까 시험 문제를 교체해버리는 격인데, 그렇다면 왜 테스트를 고쳐야 할까? 테스트를 고치는 일에는 어떤 가치가 존재하는 걸까?

테스트를 고치게 되는 것에는 두 가지 가치가 존재하는데, 첫째는 Regression Test(회귀 테스트), 둘째는 Specification by Example(예제를 통한 명세)이다.

1. Regression Test(회귀 테스트)

Regression Test를 한국어로는 회귀 테스트라고 하는데, 이 회귀 테스트는 회귀 버그가 있는지를 찾는 것을 의미한다. 회귀 버그는 이전에 제대로 동작하던 소프트웨어 기능에 문제가 생기는 것을 가리키며, 대체로 프로그램 변경 중에 뜻하지 않게 발생한다. 이 테스트를 통해 개발자는 내 코드에 대한 자신감과 안정감이 생기고, 코드에 대한 리팩터링이 가능해진다.

그렇다면 어떻게 하면 될까!?

절차

항목	내용
Record & replay 테스트	CASE 툴을 이용하여 최초 테스트 상황 Recording 후, DataPool을 이용하여 테스트 데이터를 변경시키면서 반복적으로 테스트 -> 테스팅 비용 절감
전략적 Test case 설계	회귀 테스트 케이스 시나리오는 가변적이기 때문에 최초에 테스트 케이스를 미리 예측 작성하는 것은 어려움. 테스트를 진행하면서 수행하는 결함 조치 결과에 기반한 시나리오로 테스트 케이스를 유동적으로 신규 작성하는 테스트 계획 수립이 필요
주요 대상 선정	응집도가 높은 모듈 내부 보다는 모듈간 결합도가 높은 부분에 집중해서 반복 수행
반복 횟수 선정	회귀 테스트 반복횟수 지정 기준 마련(예: 기본적으로 해당 부분에 3회 이상 반복 수행하되, 결함발생율이 이전보다 10% 미만으로 떨어지면 회귀 테스트를 완료한다.)

2. Specification by Example(예제를 통한 명세)

프로그램을 일일이 실행시켜보지 않아도 명세 자체를 여러 가지 예제를 통해서 알 수 있다. 예제를 통한 명세는 추상적인 설명 대신 현실적인 예제를 사용해 요구 사항을 캡처하고 설명하는 것을 기반으로 하여 소프트웨어 제품에 대한 요구사항과 비지니스 로직 테스트를 보다 더 쉽게 이해할 수 있게 해 준다. 즉, 현재 소프트웨어의 상황을 소스 코드를 별도로 읽어보거나 실행해보지 않아도 사용자 입장에서 어떻게 돌아갈지를 예제를 통해 바로 이해할 수 있다는 것이다.