[옛날 블로그 글입니다. 2009.01.10]

Google에서 사용하는 코딩 가이드라인이 있네요. 테스트하기 좋은 코드를 만들기 위한 가이드라인으로 크게 4가지 얘기를 하고 있습니다. 바쁘고 영어 싫어하시는 분들을 위해서 간단히 정리해보겠습니다. 원문은 아래 주소에서 보세요~  http://misko.hevery.com/code-reviewers-guide/

결함 #1: 생성자가 실제적인 일을 한다

생성자에서 너무 많은 일을 하면 테스트가 어려워 집니다. 테스트를 위해 오브젝트를 생성하기도 어렵고, 협력 오브젝트로를 바뀌치는 것도 어렵죠. 

경고 신호

• 생성자에 있는 new 키워드 ( Java/C#이라면 필드 선언에 있는 new 키워드) 
• 생성자에서 스테이틱 메소드 호출 (역시 필드에서의 호출도)  
• 필드(멤버 변수) 대입 이상의 모든 행위  
• 생성자가 끝나도 오브젝트가 완전히 초기화되지 못했다 (initialize 메소드를 주의할 것)  
• 생성자에 있는 제어 코드(조건문이나 반복 로직)  
• 생성자에서 복잡한 오브젝트 그래프를 생성한다, 팩토리나 빌더를 사용하는 대신에
• (Java의)초기화 블럭을 사용한다   

왜 결함인지

생성자에서 협력 오브젝트를 생성하거나 초기화하면, 유연하지 못하고 너무 일찍 커플링된 디자인이 되기 쉽습니다. 테스트용의 협력 오브젝트로 바꿔칠 기회도 잃어버립니다.

Single Responsibility Principle에 위배된다.

클래스는 하나의 책임만 가져야 합니다. 오브젝트 그래프를 생성하는 것도 충분히 하나의 책임으로 볼 수 있으므로 위배.

직접 테스트 하기 어렵다.

테스트에서 오브젝트를 생성할 때도 생성자가 샐행되지요. 생성자에 있는 협력 오브젝트가 외부 리소스(파일, 네트웍, DB)에라도 접근한다면, 협력 오브젝트의 작은 변화도 생성자에 영향을 줍니다. 그런데 협력 오브젝트의 테스트가 어려우니까 테스트 코드를 빼먹었을 수도 있겠죠. 그럼 또 내 오브젝트가 테스트가 충분히 안된 셈이니 악순환.

테스트를 위한 상속과 오버라이딩은 여전히 결함을 갖는다.

생성자에서 거의 아무것도 안하고 오버라이드될 함수에 일을 떠넘기는 경우. 복잡한 생성 문제는 피할 수 있을지 몰라도, 테스트를 위한 상속은 최후의 보류로 하는게 좋답니다. 또 오버라이드된 함수를 테스트 할 수 없게 되는데, 이 함수가 많은 일을 하고 있으므로 반드시 테스트 되었어야 합니다.

협력 오브젝트를 강요한다.

뭐 계속 했던 얘기. 협력 오브젝트는 생성자의 인자로 넘기는 것을 강추. 그리고 테스트 용의 생성자를 따로 만드는 것은 비추. 그 클래스를 쓰는 또 다른 클래스를 테스트 하려면 피곤해지니까요.

결론

결국 독립적인 생성 혹은 테스트용의 협력 오브젝트를 사용한 생성이 얼마나 어려운가의 문제입니다. 

• 어렵다면, 생성자에서 너무 많은 일을 하는 겁니다!   
• 쉽다면, 스스로를 칭찬하세요.    

원문을 보시면 아래처럼 더 읽어보실만한 내용이 있습니다. 직접 확인해주세요 ^^ 

• 결함 인식하기  
• 결함 고치기   
• 구체적인 코드 예 (Before and After)  

나머지 3개의 결함은 다음에 포스팅 하겠습니다. ^^ 

결함 #2: 협력 오브젝트 속으로 파고 들기 
결함 #3: 깨지기 쉬운 전역 상태&싱글톤
결함 #4: 클래스가 너무 많은 걸 한다

마무리

테스트 하기 좋은 코드는 좋은 코드입니다. 말이 좀 이상한가요 -_-;; 테스트 하기 좋게 코드를 작성하면 자연스레 좋은 품질의 코드가 만들어진다는 의미인데요. 어찌보면 당연하기도 합니다. 내가 만든 클래스를 가져다 쓰기가 쉽다는 말이 되니까요.

또 반대로 품질이 안좋은 코드는 테스트 하기가 어렵습니다. 그래서 우리도 한 번 유닛테스트 도입해보자! 라고 큰맘먹고 해보려고 해도 좀처럼 쉽지 않은 경우가 많은데요, 유닛테스트가 어려운 것으로 탓하고 포기하지 마시고 조금씩 리펙토링 하면서 테스트를 만들어 보시면 재밌습니다. ^^

그럼 가이드라인 참조하셔서 좋은 코드 만드세요~