loading...

OKKYCON 2018 - The Real TDD ' TDD 제대로 알기 '

' OKKYCON : 2018 - The Real TDD' : TDD 제대로 알기

지난 10월 18일 삼성SDS West Campus 마젤란홀에서 전일 행사로 개최된 'OKKY Conference 2018' 행사의 참관기 입니다.
이번 ‘OKKYCON: 2018’ 개발자 컨퍼런스의 주제는 'The Real TDD – TDD(Testable-code-driven Development) 제대로 알기' 였습니다. 이 행사는 TDD와 관련하여 한국 대표 Tech 기업·스타트업의 실무를 이끄는 개발 리더들 및 SW 교육 최고 전문가가 강의 / Live Coding / 열띤 토론으로 많은 노하우와 인사이트를 얻을 수 있었습니다.

OKKYCON은 한국 최대 개발자 커뮤니티 OKKY가 개발자 커뮤니케이션과 협업을 위해 각 분야 개발 전문가를 초청하여 실무경험, 업무환경, 올바른 협업과 노하우를 공유하는 컨퍼런스로 매년 개최되고 있습니다. 현재는 자바를 넘어 모든 개발자를 아우르는 커뮤니티로 확대되어 현재 6만 명이 넘는 회원이 활동하고 있습니다.

저는 현재 코드리뷰, 클린코드, 리팩토링 등의 업무를 수행하고 있어서 TDD와 많은 관련이 있어 세미나에 참석하게 되었으며 업무에 많은 도움이 되기를 기대하면서 참석하게 되었습니다.
다음과 같은 질문을 던지며 컨퍼런스의 문을 열어 보겠습니다.


"
TDD는 죽었다 ?
TDD는 실무를 해결할 수 없다 ?
비즈니스 현장에서의 개발 생산성을 향상시켜 주는 실전형 TDD !
"

이번 컨퍼런스에서는 TDD에 관심을 가지고 시도/도전해보았지만 방향을 잃거나 실패하신 분들이 TDD를 실제 비즈니스에 적용하여 개발 부담은 낮추고 코드 품질은 높일 수 있도록 실제 사례를 기반으로 다양한 연사들의 강연을 들을 수 있었습니다.

여기서는 전체적인 컨퍼런스 분위기와 세션들에 대한 요약을 간단하게 공유하려 합니다. TDD에 대하여 상세한 개념을 알지 못하는 분들도 TDD란 이런 것이구나 이렇게 적용하는구나 하는 느낌으로 읽으실 수 있는 글이 될 것 같습니다.

전체 행사의 아젠다는 다음과 같습니다.

아젠다

주요 세션 둘러보기

⌈테스트하기 쉬운 코드로 개발하기⌋

  정진욱 - PUBLYTO CPO
정진욱 개발자의 테스트하기 쉬운 코드로 개발하기

TDD가 어려운 이유는 테스트 기술이 부족해서가 아니라 테스트 대상 코드가 테스트하기 힘들게 디자인되었기 때문이라는 정진욱 님의 이야기로 시작되었습니다. 테스트하기 쉬운 코드란 같은 입력에 대하여 같은 결과를 제공하고 외부 상태를 변경하지 않는 코드라고 합니다.

일반적으로 DB를 사용하는 프로그램의 경우 테스트하기가 어려우며 이는 DB에 테스트데이터를 설정해야 하기 때문입니다. 그래서 테스트 하기 어려운 코드는 다음의 과정을 통하여 개선이 필요하다고 합니다. 우선 테스트하기 쉬운 코드와 어려운 코드를 분리하도록 합니다. 이를 위하여는 일반적으로 함수를 분리하는 방법을 쓴다고 하네요.
다음에는 두 부류의 코드가 최대한 가장자리에서 만나게 하고 Google의 Postman 등의 플러그인을 활용하여 자동화 테스트를 수행(POST Method)한다고 합니다. Mock을 사용하기도 하는데 대부분 Mock의 예제가 간단하기 때문에 사용이 쉬워 보여도 실제 프로젝트에 적용하면 한꺼번에 많은 수의 Mock을 다루면서 곤란을 겪는다고 하네요.

최근에 연사께서는 두 부류의 코드를 분리해서 각각 테스트하고 가장자리에서 맞물려 돌아가는 코드는 주로 수동테스트를 수행한다고 하네요. 자세한 내용은 다음 연사의 블로그에서 참고하실 수 있습니다.
(블로그 참조 : http://jwchung.github.io/testing-oh-my)

⌈의식적인 연습으로 TDD, 리팩토링 연습하기⌋

  박재성 - SW 교육 전문가 전 NEXT 교수
박재성 교육 전문가의 리팩토링 연습하기

박재성 님은 NEXT 교수를 지내셨고 현재 SW교육전문가로서 자바지기로도 활동하시고 계신 연사였습니다. 주로 교육과 관련한 업무를 오랫동안 해오신 경험으로 TDD를 연습할 수 있는 방법에 대하여 아주 자세하게 설명을 해 주셨습니다.

먼저 레가시 시스템에 적용하기 전에 반드시 Toy 프로젝트를 가지고 연습을 하여 흥미를 가지고 익숙해지면 레가시 프로젝트에 적용해 보라고 가이드 주셨습니다. Toy 프로젝트로는 로또, 사다리 타기, 체스게임 등(단 UI는 콘솔)이나 입력과 출력이 명확한 프로그램을 추천하셨습니다.

그리고 한 단계 더 나아간 연습을 하기 위하여 다음과 같은 접근방식을 권유하셨답니다.
우선 컴파일 에러를 최소화하면서 리팩토링을 하고 다음에는 ATDD기반으로 응용 어플리케이션 개발한 후에 마지막으로 레가시 애플리케이션에 테스트 코드를 추가하여 리팩토링하는 방법에 대하여 알기 쉽게 설명해 주셨습니다.

⌈코드 품질을 위한 테스트 주도 개발⌋

  한성곤 - 삼성SDS Principal Engineer
삼성sds 수석엔지니어 한성곤의 코드 품질을 위한 테스트 주도 개발

한성곤 님은 “코드 품질을 위한 테스트 주도 개발” 주제를 가지고, TDD 가 코드 품질에 주는 영향을 설명하시면서 다양한 코드 품질 지표를 상세하게 설명해주셨습니다.

일단 TDD 에 대해 개념 설명 및 Test Frist 나 테스트 자체에 대한 특성을 간략하게 설명해 주셔서 TDD에 대해 정리하는데 도움이 되었던 것 같습니다. 또한, SonarCloud에 등록된 다양한 프로젝트를 분석하여 그래프로 시각화하여 보여주신 덕분에 단위 테스트 커버리지와 코드 품질 지표의 값 간의 상관관계가 명확하게 보여서 단위 테스트의 중요성을 쉽게 알 수 있었죠. 또한 평소 의미파악이 쉽지 않았던 코드 품질 지표에 대해 샘플 코드나 수식을 상세하게 설명해주셔서 코드 품질 지표의 의미를 잘 이해할 수 있었습니다.

우선, SonarCloud에 등록된 다양한 프로젝트를 분석한 결과를 요약해 드리자면 단위 테스트 커버리지가 80% 이상일 경우, 중복도 및 복잡도 등의 코드 품질 지표가 현격하게 좋아졌다는 것을 쉽게 인지할 수 있었습니다. 또한 마이크로소프트에서 TDD를 수행하지 않은 프로젝트와 수행한 프로젝트 간의 출하된 이후 버그 발생 비율로 현격하게 줄어드는 것을 알 수 있었습니다.

또한 TDD를 통해 향상되는 코드 품질 지표에 대한 설명 중에는 평소 자주 들어보았던 McCabe Cyclomatic Complexity 이외에 Robert Martin Metrics 나 Cognitive Complexity, Lack of Cohesion of Methods 등의 품질 지표에 대해 클래스 다이어그램과 소스코드 등으로 하나하나 계산해가면서 설명해 주셨습니다. Robert Martin Metrics의 경우 추상 수준과 불안정성 수준을 X, Y 좌표로 두고 인터페이스 개수나 Dependency 개수를 이용하여 소프트웨어의 품질 정도를 가시화하여 표현한다는 것이 인상적이었죠. Cognitive Complexity 의 경우 SonarQube 에서 중요시하는 코드 품질 지표라서 향후 코드 품질의 주요 척도로 될 것 같다고 알려주셨는데, 제가 봐도 Cognitive Complexity 는 들여쓰기가 여러 단계로 구성되면 코드의 가독성이 저하된다는 실질적인 느낌을 잘 반영한 코드품질 지표라는 생각이 들었습니다.

⌈테알못 신입은 어떻게 테스트를 시작했을까?⌋

   이혜승 / 오마이호텔 Front-End Engineer
이혜승 개발자의 tdd를 신입에게 어떻게 테스트 시작했을까?

이혜승 님은 입사한 지 채 6개월이 지나지 않은 개발자였지만 그 짧은 기간 동안 TDD를 정말 정석대로 배우신 분 같았습니다. 초보 개발자로서 TDD를 경험한 내용에 대하여 아주 상세하게 소개해 주셨습니다.

특히 기존 코드에 테스트 코드를 추가하는 방법이라든가 아니면 새로운 코드를 TDD로 개발하는 방법에 대하여 느낀 점을 이야기해 주었습니다. 테스트 코드를 작성함으로써 좋았던 점은 불안을 감소하고 스펙 문서 기능을 제공하며 학습 동기를 부여하여 안정성과 설계에 관심을 가지고 특히 디버그 시간이 줄어들면서 개발 생산성이 향상되고 비즈니스 로직의 허점을 일찍 발견하여 프로젝트 생산성을 향상 시킬 수 있었다고 합니다. 또한 지금 당장 내가 해야 할 일에 대하여 집중할 수 있었다고 하네요.

반면에 여러 가지 실수들을 경험하였다고 하는데요, 테스트 자체에 대한 지나침으로 불필요한 테스트를 양생하거나 필요하지만 검증 방식이 잘못된 테스트, 검증력이 떨어 지는 테스트, 또 테스트를 앞서 가는 프로덕션 코드를 작성해 본 경험이 있다고 하네요.

마지막으로 Fixture에 대한 효과적인 관리라든가 리팩토링을 하면서 함수가 계속 분리되고 있는데 이게 맞는 것인지, 낮은 추상화 수준과 응집도를 높이고 결합도를 낮추는 방안에 대한 부분을 계속 고민중이시라고 합니다.

⌈테스트를 돌보기 위한 매우 간단한 실천 방법들, 그리고 효과⌋

  양완수 – 쿠팡 Principal, Software Engineer
양완수 쿠팡 개발자의 테스트를 돌보기 위한 매우 간단한 실천 방법들과 효과

양완수 님은 “테스트를 돌보기 위한 매우 간단한 실천 방법들, 그리고 효과”라는 주제를 가지고, TDD 나 리팩토링 보다는 단위 테스트 자체에 대한 많은 이야기를 주셨습니다.
"테스트를 왜 하지 않게 되나?" 라는 화두를 던지고, 단위 테스트를 하기 위해서는 쉽지 않은 노력이 들어가는데, 그래도 테스트를 하고 싶다는 분들이 있다면, 그 분들을 위해 테스트 할 때 알아두면 도움될 만한 내용을 주로 다루겠다고 하셔서, 저도 완전 집중해서 듣게 되었습니다.

우선, 테스트를 돌보기 어려운 이유를 "숨겨진 본질", "욕심쟁이", "의도를 모름", "깨지기 쉬운 것들" 등으로 나누어 설명하셨는데, 만약 어제 테스트 케이스를 작성했다면 테스트 케이스를 만든 사람은 내가 아니라, 어제의 “나”이고 지금 그 테스트 케이스를 보는 사람은 어제의 “나”와 다른 지금의 “나”이기 때문에 같은 사람이 아니라는 말에 극히 공감이 갔습니다. 그렇기 때문에 테스트 케이스는 지금의 내가 아닌 다른 사람 (여기에는 미래의 “나”를 포함하는 것이겠지요.)을 위해 작성하려면 돌보기 어려운 이유를 살펴보는 것도 좋은 방법이라고 생각되었습니다.

설명해주신 여러가지 이유에서 저에게 중요하게 느껴졌던 키워드를 골라보자면, “숨겨진 본질”과 “욕심쟁이”를 꼽을 수 있습니다. “숨겨진 본질”의 핵심은 추상화가 낮거나 균일하지 않은 점이 테스트 케이스를 이해하기가 어렵게 만든다는 것 입니다.
“욕심쟁이”의 핵심은 테스트 케이스 별로 실패의 이유가 하나씩만 되도록 작성해야 한다는 것 입니다. 만약 욕심을 부리게 되면 테스트 케이스를 유지하기 어렵게 만들게 됩니다. 예를 들어, 테스트 케이스에서 테스트 대상이 명시되어 있지 않거나, 테스트 목적이 쉽게 인지되지 않으면 점차 테스트 케이스를 유지하는 것이 어려워지고 결국 테스트를 결국 포기하게 되어버리죠. 때문에, 추상화도 균일하게, 테스트 실패의 이유도 하나만 갖게 하고, 테스트의 목적이나 대상이 명확하게 되도록 테스트 케이스를 유지하는 것이 좋다고 설명하시면서, 아주 복잡한 테스트 케이스가 읽기 쉽게 변경되는 모습을 보여주셨습니다.

끝으로 테스트가 주는 가치는 배움, 성장, 즐거움이라고 끝맺음을 하셨는데, 다 듣고 나니, 옛말에 불여락지자(不如樂之者) 라고 하더니, 비단 테스트뿐만 아니라, 모든 일에 있어서, 궁극의 깨달음은 즐거움에서 온다는 것을 새삼 느낄 수 있었던 감사한 시간이 된 것 같았습니다.

⌈당신들의 TDD가 실패하는 이유⌋

  이규원 – 오마이 호텔 CTO
이규원 CTO의 당신드르이 TDD가 실패하는 이유

이규원 님은 “당신들의 TDD가 실패하는 이유는?” 이라는 질문에 대해 "준비가 되지 않아서" 라고 설명하면서 세션을 시작했습니다.
준비하는 과정에 있어서 TDD로 할 수 있는 것과 TDD 로 할 수 없는 것으로 나누어서 접근해야 했습니다. 우리가 TDD로 할 수 있는 것은 도메인이며 할 수 없는 것은 실세계, 인프라, 레거시 코드 등이 있는데, 이를 분리하기 위해 “높은 응집도와 낮은 결합도”로 요약되는 설계 기법의 도입이 필요하다는 것을 강조했습니다.

또한 개인 차원에서 TDD 준비는 정보 은닉 관점에서 설계하는 역량을 확보하는 것과 팀차원에서 TDD를 잘하기 위해서는 반복점진적인 프로세스의 적용을 꼽았습니다. 이와 더불어 공유하는 문화, 플랫폼과 도메인을 분리하는 아키텍처를 언급하셨는데 플랫폼과 개발자 코드를 분리하는 내용은 저도 실무에서 소프트웨어 아키텍처를 수립할 때 각별하게 주의해서 설계하고 구현했던 부분이라 마음에 많이 와 닿았습니다.

TDD 준비에 필요한 이야기를 마치고, 이후에는 개발자 컨퍼런스 느낌이 물씬 나게 영화예매 시스템을 예제로 라이브 코딩을 하면서 발표를 마치셨는데요. 발표 후 나오는 질문도 ①초급 개발자 멘토링, ②요구사항 정의 관련 및 단위 테스트 작성 시 외부 환경 문제 등과 같이 고급 개발자가 많이 참석한 컨퍼런스인 만큼 수준이 높았고, 이론과 실무 경험을 기반으로 한 답변을 듣는 것만으로도 좋은 공부가 되었던 자리였습니다.

마지막에는 TDD의 한계점에 대해서도 언급해주셨습니다. 테스트 케이스 작성 시, 구현에 의존적으로 작성되는 경우가 종종 발생하여 불필요한 테스트 케이스의 수정이 빈번해질 수 있기 때문에, 그 대안으로 업무 시나리오에 맞추어서 작성하는 BDD (Behavior-Driven Development)를 적용하면 구현에 의존해서 작성되는 테스트 케이스의 빈번한 수정 문제가 완화될 수 있다고 알려주시며 마무리를 하셨습니다.

TDD 뿐 아니라, TDD를 통해 얻을 수 있는 코드 품질과 향후 TDD가 발전될 방향을 알게 되어 개인적으로는 코드 품질을 바라보는 수준이 향상된 것 같아 좋은 시간이 되었습니다.

⌈패널토의⌋

마지막으로 패널 토의가 있었습니다. 사전에 질문을 다음과 같이 받아서 진행자가 질문을 선택하여 패널간 토론하는 방식으로 진행되었죠. 저도 질문을 올렸었는데 아쉽게도 채택이 되지는 않았네요.
Test Coverage 확보에 대한 질문과 TDD를 팀 내에서 어떻게 확대해야 하는지에 대한 질문이 나와서 패널분들이 많은 의견들을 주셨답니다.

패널토의

마무리

이번 컨퍼런스를 통해서 다른 회사에서 실제로 TDD를 어떻게 적용하고 있는지를 알게 되었고 그들도 우리와 같은 고민들을 하고 있다는 것을 알게 되었습니다.
그리고 TDD를 한 번에 적용하려 하기보다는 조금씩 작게 점진적으로 확대해 나가야겠다는 생각이 들었고 저도 어서 업무에 적용해 보고 싶은 생각이 들었습니다. 앞으로도 이러한 컨퍼런스가 자주 개최되어서 TDD뿐 아니라 코드리뷰, 리팩토링, 클린코드 등의 문화와 역량이 갖춰진 개발 문화가 정착되기를 기대해 봅니다.



▶   해당 콘텐츠는 저작권법에 의하여 보호받는 저작물로 기고자에 저작권이 있습니다.
▶   해당 콘텐츠는 사전 동의없이 2차 가공 및 영리적인 이용을 금하고 있습니다.



이 글이 좋으셨다면 구독&좋아요

여러분의 “구독”과 “좋아요”는
저자에게 큰 힘이 됩니다.

subscribe

구독하기

subscribe

김동식
김동식 IT테크놀로지 전문가

삼성SDS 개발실

코드품질그룹에서 클린코드, 코드리뷰, 리팩토링 문화 확대와 역량강화의 업무를 수행하고 있습니다. 현재는 우면캠퍼스에서 근무중입니다.

공유하기