•
코드를 변경하기에 앞서, 기존 동작의 명세를 확실히하고자 테스트를 작성해야 할 때, 어디에 작성해야 할까?
◦
가장 간단한 답은 변경 대상 메소드마다 테스트 코드를 작성하는 것이다.
•
하지만 이렇게 간단하게 답을 낼 수 있는 문제가 아니다. 코드가 간단하다면 충분하지만 레거시는 그렇지 않은 경우가 더 많다.
•
테스트 루틴이 적절하지 않으면 어떤 영향을 미칠지 전혀 알 수 없기 때문에 우리는 테스트 코드의 위치를 결정하는 데 많은 시간을 보내야 한다.
◦
리팩토링은 결과를 바꾸지 않으면서 동작을 변경하는 과정이다. 리팩토링 전 결과를 알고 있어야 한다.
•
이번 장은 이런 간극을 메우기 위한 기법들을 설명한다. 테스트 코드의 최적 위치를 찾기 위해서는 다양한 영향들에 대해 제대로 추론해야 할 때가 많다.
영향 추론
•
우리가 변경한 코드가 어디까지 영향을 미칠지 추론하는 기법에 관한 내용이다.
•
영향을 효과적으로 추론하기 위해 영향을 받는 변수와 반환 값이 바뀔 수 있는 메소드를 타원으로 그려 서로 화살표로 연관짓는 다이어그램을 활용해볼 수 있다.
◦
값이 바뀔 변수를 타원으로 그린 후, 변수 값의 변경으로 인해 반환 값이 변경될 여지가 있는 메소드를 향해 화살표를 그린다.
◦
이런 추론을 충실히 해내면 예상치 못한 오류가 발생했을 때, 어느 지점을 조사해야하는 지 빠르게 파악할 수 있다.
•
품질이 좋지 못한 프로그램은 결과 값을 도출하기까지의 과정을 파악하기 어려울 때가 많다. 당연히 디버깅도 어려워진다.
•
레거시 코드를 다룰 때는 수시로 다음 질문에 대답해야 한다. 어떤 변경을 수행하면, 그 변경이 프로그램의 나머지 부분에 어떤 영향을 미칠까?
◦
이 질문에 답하려면 변경 지점을 기준으로 전방 추론을 해야 한다. 전방 추론을 잘하는 것은 테스트 루틴의 최적 위치를 찾는 기법의 기초를 닦는 것이다.
전방 추론
•
명세에 관한 테스트를 작성할 때는, 먼저 객체들을 조사하고 이 객체들이 제대로 동작하지 않을 경우, 어떤 영향을 미치는지 추론한다.
•
내가 변경하려는 코드의 변경 지점을 설정했을 때, 해당 변경 지점에 영향을 줄 수 있는 곳들을 파악하여 영향을 감지하는 테스트 루틴을 작성해 코드를 보호한다.
•
테스트 위치를 찾아야 할 때, 가장 먼저 할 일은 어디서 변경을 탐지할 수 있는지, 즉 변경의 영향이 무엇인지 파악하는 것이다.
영향 전파
•
일반적으로 영향이 전파되는 방법은 변경하려는 코드의 반환 지점이나 메소드가 대표적이었다.
•
이들은 공개적인 전파에 속하는데 은밀하게 전파되는 경우도 존재한다. 대표적으로 다른 객체를 매개변수로서 받아 속성을 변경시키거나 전역 변수, 정적 변수들이 해당한다.
◦
관점 지향 언어를 사용하는 경우, 관점이라는 구조를 통해 전파되기도 한다.
•
다음은 저자가 경험적으로 변경 영향을 탐색할 때 사용하는 방법이다.
1.
변경 대상 메소드를 식별한다.
2.
메소드가 반환 값을 가진다면 이 메소드가 호출하는 코드를 살펴본다.
3.
메소드가 어떤 값을 변경한다면 그 값을 사용하는 메소드와 다시 이 메소드를 사용하는 메소드를 살펴본다.
4.
인스턴스 변수 및 메소드 사용자가 될 수 있는 슈퍼클래스와 서브클래스도 살펴본다.
5.
메소드에 전달되는 매개변수를 살펴본다. 변경하고자 하는 코드가 매개변수나 반환 값인 객체를 변경하지 않는지 살펴본다.
6.
식별된 메소드 중에서 전역 변수나 정적 변수를 변경하는 것이 있는지 살펴본다.
•
위 방법들을 사용하면 대부분의 영향 전파를 잡아낼 수 있다.
영향 추론을 위한 도구
•
프로그래밍 지식을 쌓는 것도 중요하다.
•
영향 전파를 효과적으로 막아주는 방화벽을 하는 const, private 등 키워드들이 많이 있다. 이들을 알아두고 영향 전파에 적절히 사용하자.
⇒ 영향 전파는 캡슐화와 연관이 굉장히 깊어보이는데, 추론을 위해 캡슐화를 잘 공부해두면 좋을 것 같다.
영향 분석을 통한 학습
•
좋은 코드에는 뭔가 새고 있는 구멍이 없다. 편의를 위해 잠깐 눈 딱 감고 오픈할 수 있으나 이는 곧 나중의 내가 힘들어질 뿐이다.
•
프로그램 내의 영향을 줄일수록 프로그래밍이 쉬워진다. 내가 지금 해결해야할 문제에만 집중할 수 있기 때문이다.
영향 스케치의 단순화
•
중복 부분을 제거하여 영향 스케치의 종점 수를 줄일 수 있다. 이는 즉, 테스트 구별이 좀 더 간단해짐을 의미한다.
•
영향을 약식으로 추론할 수도 있고 영향 스케치를 사용해 엄밀하게 추론할 수도 있다. 하지만 가급적 영향 스케치를 사용하면 좋을 것이다.
◦
매우 복잡한 코드를 대상으로 작업할 때, 테스트 루틴의 위치를 발견하는 과정에서 우리가 의지할 몇 안되는 기법이기 때문이다.
