개요

왠지 모르게 어디선가 들어서 유명하다는 것을 알고 있는 책.. 클린 코드에 이어서 2탄이네요. 곰곰히 생각해보면 뭔가.. 신기(?)합니다. 이 책을 어떻게 어디서 알게 되었는지, 많고 많은 테스트 관련 개발 서적 중에 왜 하필 이 책을 선택했고, 클린코드를 같이 선택해서 책 2개를 먼저 확 사버렸는지… 전혀 기억이 나질 않습니다. 이렇게… 늙어가는 걸까요…?

너무 의식의 흐름대로 글을 시작해버렸네요,, ㅎㅎ 이만 각설하고.

저는 “테스트 코드” 그 자체에 대해서 고민해볼 수 있는, 논의해볼 수 있는, 생각해볼 수 있는 어떠한 기회를 가지고 싶다.. 하는 생각을 꾸준히 가지고 있었습니다.

회사에서 나름 이상적이라고 생각하는 저의 방식대로 테스트 코드를 작성하고 있지만, 그것이 정말 올바른 방식인지, 올바르다면 그것의 근거 혹은 이론적인 배경은 무엇일지, 혹은 틀리다면 개선할 방법은 무엇이 있을지 알고 싶었습니다.

책을 읽으면서 제 방식에 대해서 근거도 얻고 조금 수정도 하고, 많은 좋은 생각들을 배운 것 같습니다. 그 이유 중에 하나로, 이 책은 테스트 코드 뿐 만 아니라 좋은 코드 구조에 대해서도 알려줍니다. 좋은 테스트 코드를 작성하려면, 테스트 대상 코드부터가 좋은 구조로 짜여져있어야 한다는 사실도 많이 느꼈습니다.

이 책을 읽으면서 이런 저런 생각들을 해볼 수 있었던 것 같습니다. 조금 기록해보겠습니다! (음… 지금부터 작성할 글 내용을 미리 생각해보니.. “테스트 코드” 라는 내용 자체와는 조금 거리가 있을 수도 있겠네요. 어느덧 4년차가 되어(햇병아리지만ㅋㅋ), 여러가지 경험 때문에 떠오르는 이런 저런 생각들이 이 책을 읽으면서 좀 더 구체화된 것 같은 느낌이네요.)

단위 테스트

블라디미르 코리코프 저/임준혁 역

소프트웨어 개발에 있어 단위 테스트는 이제 선택이 아니라 필수가 됐다. 단위 테스트에 대한 오해를 바로잡고, 올바른 단위 테스트에 대한 원칙, 테스트를 작성하는 스타일과 효과적인 테스트를 위한 소프트웨어 아키텍처를 이해할 수 있다. 또한 단위 테스트를 통합 테스트와 구분하고, 둘의 차이와 각각 활용법과 적절한...

책은 넓은 견해를 알려주고, 이는 팀원과 생산적인 소통에 도움이 된다.

책의 처음 부분을 보면 단위 테스트를 작성하는 방식의 취향 차이 때문에 “고전파” 와 “런던파” 2개의 분파가 나뉘어 졌다는 내용이 나오는데요, 각각의 차이는 아래와 같습니다.

• “고전파”
  • 테스트 대상은 하나의 단위라서 여러 클래스를 걸친 하나의 로직이 될 수 있고, 공유 의존성만을 목으로 대체한다.
  • 단위 테스트와 테스트 주도 개발에 원론적으로 접근하는 방식이기 때문에 “고전파” 라고 하고..
• “런던파”
  • 테스트 대상은 단일 클래스이고, 불변의존성을 제외한 모든 의존성을 목으로 대체한다.
  • “목 추종파” 로도 불리는데, 런던의 프로그래밍 커뮤니티에서 시작됐기 때문에 “런던파” 라고 이름 붙여졌다고 합니다.

상당히 신선한 이야기라서 여러번 검색해보았는데, 9년 전 레딧에 이런 글도 있고 , Medium 에도 여러 글들이 있는 걸로 보아 상당히 오래된 논쟁거리인 것 같습니다.

ㅎㅎ… 좀 재밌습니다. 테스트 코드에 대한 서로 다른 견해와 취향때문에 파가 나뉘어졌다니. 좀 생각해보니 테스트 코드 말고도 코딩 스타일이라던가, 아키텍처 취향이라던가..(헥사고날 반대파!? 등) 분파가 나뉠만한 여지가 있는 부분이 우리 개발자 생태계에 상당히 많네요. 당장에 회사에서 맡고 있는 프로젝트에도 코드 스타일이 각자 달라서 동일한 intelliJ 설정 파일을 덮어씌워야 유지되니.. 물론 저는 지금 프로젝트의 코딩 스타일이 마음에 들지 않습니다 ㅠ.. 그래도 좀 더 나은 가독성과 유지보수성을 위해서는 프로젝트별 동일한 코드스타일 유지가 필요하다고는 생각합니다.

아무튼.. 이야기가 조금 샜는데, 본론으로 돌아가자면.

저에게는 이 “고전파”, “런던파” 내용이 상당히 신선했고, 이 책이 아니었다면 꿈에도 몰랐을 지식이라고 새삼 느꼈습니다. 그리고 이런 새로운 지식들이 팀원과 협업을 위한 소통에 많은 도움이 될 것 같다는 생각이 불현듯!! 들었습니다.

예를 들어, 팀원과 테스트 코드 컨벤션에 대해서 논의하는 중이라고 하면..

• A는 “테스트 대상을 확실히 격리하고 명확하게 하기 위해서는 변하지 않는 의존을 제외한 대부분의 의존을 목으로 대체해야 합니다. 테스트 실패는 테스트 대상에 의해서만 발생되어야 합니다. 그리고 가능한 하나의 클래스가 단위로서 명확하게 설정되어야 합니다.”

라고 주장할 때

• B는 “그건 과한 오버엔지니어링 테스트 입니다. 테스트 대상인 “단위”는 어떠한 하나의 행위라고 할 수 있고, 이는 여러 클래스에 걸쳐있을 수 있습니다. 또, 목을 줄이면 테스트가 유지보수에 강하고, 테스트 대상이 의존하고 있는 대상도 테스트 커버리지에 포함되어 코드의 안정성도 높아집니다.”

라고 말할 수 있습니다. 이렇게 자신만의 의견이 있는 논의를 시작할 때, 대부분은 자신의 생각이 조금 더 적절하고 옳다고, 혹은 정답이라고 굳게 믿고 있을 겁니다. 이 때!! 이런 이야기를 하는 거죠.

• “두 분이 주장하시는 서로 다른 의견이 사실 오래된 논쟁거리 였는데요~! A님은 켄트 백의 “테스트 주도 개발” 책의 지지자인 “고전파” 취향이신 것 같고, B님은 스티브 프리먼과 냇 프라이스의 “테스트 주도 개발로 배우는 객체 지향 설계와 실천” 책의 지지자인 “런던파” 취향이신 것 같습니다. 오래 전부터 분파가 나뉘어 논쟁되었다는 건, 정답이 없다는 거 아닐까요? 우리 프로젝트 성격에 맞는 최적의 방식을 조율해 나가봅시다!!”

이렇게 책으로 알게된 지식, 히스토리, 다양한 견해 등이 생각의 방향성이나 다른 사람의 의견에 대해서 바라보는 관점에 많은 영향을 줄 것 같습니다.

사실 저는 지금까지 B의 입장이었긴 합니다. 또, 이 견해들을 잘 모르던 상태로 A의 의견을 만나면 “어떤 방식으로 말하는 것이 내 의견을 이해하시는데 도움이 될까?” 혹은 “어떻게 피력해야 A 보다 B 의견에 장점이 더 많다는 것을 알릴 수 있을까?” 하는 생각부터 했을 것 같아요.

“내가 정답이고 상대를 이해시켜야해!” 라는 정말 오만한 생각이 베이스로 깔려있어서 진행되는 사고방식이죠..

점차 이런 고집들을 버리고, 앞으로 여러 책들을 읽으면서 여러 견해들과 지식들을 접하면 나만의 생각들이 점점 유순해지고, 이런 저런 생각의 유연성을 가지게될 수 있을 것 같아요.

이 책을 읽으면서 얻은 큰 수확을 한 문장으로 요약하자면 위가 되겠네요!

오늘도 내일도 정진합시다… 정진!