[레거시 코드 활용 전략] CH2 피드백 활용

이전글 :

2020/02/03 - [IT/책읽는 개발자] - [레거시 코드 활용 전략] CH1 소프트웨어 변경

ch 2 - 피드백 활용

시스템을 변경하는 방법에는 크게 두가지가 있다.

1. 수정 후 기도하기
2. 보호 후 수정하기

일반적인 개발 방법에서는 1번이 많이 사용된다.

1번 같은 경우 코드 변경 대상 코드를 이해하고, 계획을 세운 후 변경 작업에 들어간다.

변경을 완료하고 나서는 제대로 동작하고, 의도하지 않는 영향이 있는지 조사한다.

결과적으로 작업 결과를 확인하고 검토하는 시간이 추가로 들어가게 된다.

얼핏 보기에는 이는 매우 '신중'하고 '전문'적인 방식처럼 보인다.

그러나 아무리 신중해도 이것이 안전성에 비례한다는 보장은 없다.

 

'보호 후 수정하기' 방법은 조금 다른 방식으로 코드를 변경한다.

변경을 할 때 '안전망'을 사용하는 것이다.

여기서 '안전망'은 테스트 루틴을 의미한다.

결과 적으로 테스트 루틴으로부터 우리는 '피드백'을 받을 수 있게 되는 것이다.

 

보통 개발 완료 → 테스트 요청 → 피드백 형태를 보인다.

하지만 테스트 요청 단계는 프로그램이나 테스트 대상에 따라 시간이 많이 소요된다.

이러한 방식에 테스트는 '작업 결과의 정확성 테스트'에 해당한다.

물론 해당 목적을 위한 테스트도 꼭 필요한 단계이다.

 

또 다른 테스트는 '변경된 부분을 발견하기 위한 테스트'이다.

이러한 테스트는 정상적인 동작 여부를 확인하고 지금까지와 마찬가지로 동작 여부를 조사한다.

이러한 테스트는 동작을 고정시키고 변경하고자 하는 부분만 변경을 할 수 있게 도와준다.

단위 테스트란?

단위 테스트란 보통 함수, 클래스 단위에 테스트를 말한다.

단 하나의 클래스를 테스트하는 것은 매우 어렵다. → 대부분이 서로 결합되어 돌아가기 때문이다.

하지만 이를 분리해 테스트하는 것은 매우 중요하다.

그전에 대규모 단위 테스트의 문제점은 아래와 같다.

1. 오류 위치 파악
   • 테스트가 발생한 위치를 찾기가 어렵다.
   • 테스트 입력값을 확인하고, 오류 내용을 확인하고, 입/출력 경로 중 어디에서 발생하는지 찾아가는 과정이 오래 걸린다.
2. 실행 시간
   • 테스트 루틴이 길어질수록 실행 시간이 오래 걸린다
   • 이러한 결과로 테스트를 회피하는 횟수가 증가한다.
3. 커버리지
   • 테스트 루틴을 작성하는 시간이 오래 걸린다.

단위 테스트 즉 이러한 대규모 테스트의 단점을 보완할 수 있다.

좋은 단위 테스트는 아래와 같은 조건을 가진다.

1. 실행 속도가 빠르다.
   • 실질적인 예로 단위 테스트가 아닌 Spring 테스트를 실행했을 경우 각 테스트 케이스마다 스프링을 Bootstrap 해야 하고 해당 시간은 클래스가 늘어날수록 기하급수적을 늘어날 수 있다.
2. 오류 위치 파악에 도움이 된다.

상위 수준의 테스트

단위 테스트도 중요하지만 시나리오를 테스트하기 위해서는 상위 수준의 테스트도 꼭 필요하다.

상위 수준의 테스트를 통해 다수 클래스들의 동작을 한 번에 확인 가능하다. 

테스트를 통한 코드 보호

레거시 프로젝트에서 변경 작업을 할 때 어떤 일부터 시작해야 할까?

가장 먼저 변경을 가할 코드 주위에 테스트 루틴을 배치하는 것이다.

이러한 작업은 우리에게 '안전망'을 제공해줄 것이다.

레거시 코드를 변경하는 순서

1. 변경 지점을 식별한다.
2. 테스트 루틴을 작성할 위치를 찾는다.
3. 의존 관계를 제거한다.
4. 테스트 루틴을 작성한다.
5. 변경 및 리팩토링을 수행한다.

이러한 동작을 계속 반복하다 보면 어느새 테스트 가능한 영역이 많이 생기고, 결국 높은 커버리지를 달성할 수 있게 될 것이다.