<div id="readability-page-1" class="page"><article>
        <p><a target="_blank" rel="noopener" href="https://en.wikipedia.org/wiki/Test-driven_development">TDD</a>가 나온지 많은 세월이 지났지만 TDD를 잘알고 활용하는 개발자는 흔치 않다. 그럼에도 잊을만하면 어디선가 한번씩 언급되는 TDD이기에 자세히는 몰라도 관심을 가지고 있는 개발자는 많다.</p>
<p>어떤 개발자는 테스트 코드를 작성하는게 TDD가 아니냐고 하는 개발자도 있었다. TDD라는게 뭔가 자동화 테스트와 관련이 있는 것 같은데 자세히는 모르겠고, 막연한 뭉개구름 같은 감각적 느낌으로만 알고 있는 개발자가 흔하게 있을 정도로 TDD는 그 이름에 비해 잘 알고 있는 사람은 별로 없다.</p>
<p>나 역시 처음 TDD를 배워보겠다고 <a target="_blank" rel="noopener" href="http://www.aladin.co.kr/shop/wproduct.aspx?ItemId=37469717">TDDBE</a>라는 유명한 책을 구입했었다. 책을 구매해서 고개를 끄덕끄덕 하며 감탄하며 읽었는데, 다 읽고 난 후에 현실로 돌아왔을 때 남은 것은 막연함 뿐이었다.</p>
<p>사실 그 때는 잘 몰랐지만 지금 와서 생각해보니 TDD를 제대로 익히기 어려운 이유가 있었는데 그건 TDD가 여러 기술을 요구하기 때문이다.<br><img src="https://wonderer80.github.io/images/TDD_Global_Lifecycle.png" alt="TDD Global Lifecycle" title="보기만 해도 복잡한 TDD Lifecycle"></p>
<h2 id="TDD를-위해-필요한-기술"><a href="#TDD를-위해-필요한-기술" title="TDD를 위해 필요한 기술"></a>TDD를 위해 필요한 기술</h2><h2 id="Testing"><a href="#Testing" title="Testing"></a>Testing</h2><p>테스트를 만들어야 하니까 결국 어떤 것을 테스트할 것인지에 대한 정의가 중요하다. 안타깝게도 많은 개발자들은 테스팅 기술을 익힐 수 있는 기회가 없다. 누군가 알려준적도 없을 뿐더러 QA(라고 쓰고 테스터라고 부르는)담당자가 별도로 있는 경우가 많기 때문이다. 그래서 대충대충 빠르게 만들고 테스트는 QA 혹은 사용자에게 미루다보니 스스로 테스팅을 잘 하고 익힐 수 있는 기회가 없다.</p>
<h2 id="Test-Automation"><a href="#Test-Automation" title="Test Automation"></a>Test Automation</h2><p>TDD에서의 테스트 수행 방식은 테스트 코드를 이용한 테스트 자동화를 의미한다. JUnit이나 RSpec 같은 Testing Framework를 주로 이용한다. 많은 개발자들은 TDD에서 이 부분이 가장 어려울 것이라고 생각하지만 실질적으로는 무엇을 테스트해야할지를 어려워하는 경우가 더 많다.</p>
<h2 id="Refactoring"><a href="#Refactoring" title="Refactoring"></a>Refactoring</h2><p>TDD의 개발 Cycle 중 필수요소로 들어가는 것이 Refactoring이다. Refactroing은 기존의 동작을 변경하지 많으면서 효율적인 코드로 개선하는 작업이다. Refactoring을 하려면 Refactoring을 하기 앞서 어떤 코드가 좋은 코드인가에 대한 기반지식이 뒷받침되어야 한다.</p>
<h2 id="TDD를-배우기-어려운-이유"><a href="#TDD를-배우기-어려운-이유" title="TDD를 배우기 어려운 이유"></a>TDD를 배우기 어려운 이유</h2><p>위의 3가지 중에 하나라도 어렵게 느껴지는 것이 있는가? TDD를 잘 하려면 위의 3가지를 기본적으로 할 수 있어야한다.<br><a target="_blank" rel="noopener" href="https://ko.wikipedia.org/wiki/%EC%9D%B8%EC%A7%80_%EB%B6%80%ED%95%98">인지 부하 이론</a>에 의하면 일반적으로 과제 해결에 요구되는 인지자원의 양이 인지구조가 보유하고 있는 자원의 용량을 초과할 때 인지과부하(cognitive overload)가 발생한다고 하는데 이는 학습 부진의 주요 원인으로 본다. 쉽게 말하면 우리가 어떤 것을 배우거나 문제를 해결할 때 필요한 기반지식이 충분히 뒷받침 되지 않으면 많은 어려움을 겪게 된다는 뜻이다.</p>
<p>TDD는 위의 3가지 기술을 기반으로 설계와 개발을 어떤 식으로 할 것에 대한 개발 방법론인데 기본적인 기술에 대한 이해가 없는 상황에서 TDD를 시도하게 되면 결국 인지과부하가 발생될 수밖에 없게되고 결국 TDD 적용에 실패하게 된다.</p>
<h2 id="TDD를-안할지언정-정신-승리는-하지말자"><a href="#TDD를-안할지언정-정신-승리는-하지말자" title="TDD를 안할지언정 정신 승리는 하지말자"></a>TDD를 안할지언정 정신 승리는 하지말자</h2><p>간혹 테스트 코드를 짜냐는 질문에 자긴 TDD를 좋아하지 않는다고 답하는 개발자들을 보고는 한다. 그들이 내세우는 근거는 대부분 테스트 코드는 짜는데 시간이 많이 걸려서 효율이 좋지 않다는 것과 <a target="_blank" rel="noopener" href="https://sangwook.github.io/2014/04/25/tdd-is-dead-long-live-testing.html">TDD는 죽었다 - 번역</a>의 내용을 인용하는 것이다. 여기서 문제는 보통 이런 주장을 하는 사람들의 대부분은 테스트 자동화와 TDD를 구분하지 못할 뿐더러, 당연히 제대로 테스트 코드를 짜보거나 TDD를 경험해보지 못했다는 것이다. 사실 ‘TDD는 죽었다’라는 글을 쓴 DHH 는 테스트 자체를 반대한 것은 아니다.</p>
<p>완벽한 기술이란 없다. 하지만 본인이 지금 못한다고 해서 무조건적인 비하는 하지말자. TDD를 못한다고 볼품없는 개발자가 되는 것도 아니다. 하지만 배우기도 전에 거부하는 것은 스스로 배움의 기회를 멀리 차버리는 것과 같다.</p>
<h2 id="TDD를-꼭-배우고-싶은데-그럼-어떻게-하면-좋을까"><a href="#TDD를-꼭-배우고-싶은데-그럼-어떻게-하면-좋을까" title="TDD를 꼭 배우고 싶은데 그럼 어떻게 하면 좋을까?"></a>TDD를 꼭 배우고 싶은데 그럼 어떻게 하면 좋을까?</h2><p>어쩃든 여러분이 TDD를 배우기 어렵다는 것은 잘 알았다. 그럼 어떻게 TDD를 익혀나갈 수 있을 것인가? 가장 쉽고 빠른 방법은 TDD를 이미 잘 이해하고 사용하는 개발자에게 배우는 것이다. <a target="_blank" rel="noopener" href="https://en.wikipedia.org/wiki/Pair_programming">페어 프로그래밍</a>을 할 수 있으면 금상첨화다. 여러분 주위에 그런 사람이 있으면 그건 정말 큰 행운이라고 생각한다.</p>
<p>하지만 불행하게도(일반적으로) 주위에 그런 개발자가 없다면 결국 혼자 익히는 수밖에는 없다. 솔직히 필자는 TDD를 처음 접할 때 테스트 코드라는게 무엇인지도 전혀 이해를 못했다. 그럼에도 TDD를 개발에 적용할 수 있었는데 오히려 무지했기에 가능한 방법이었던 것 같다. 필자가 TDD를 어떤 방식으로 활용했고 배웠는지 궁금한가? 나는 무슨 방법을 써서라도 TDD를 익혀보고 싶다면 필자의 방법을 참고해보도록 하라.</p>
<p><em>다음 포스팅을 통해 필자가 익힌 邪派의 기술을 전수해주겠다.</em></p>

    </article></div>

wonderland

TDD가 나온지 많은 세월이 지났지만 TDD를 잘알고 활용하는 개발자는 흔치 않다. 그럼에도 잊을만하면 어디선가 한번씩 언급되는 TDD이기에 자세히는 몰라도 관심을 가지고 있는 개발자는 많다.
어떤 개발자는 테스트 코드를 작성하는게 TDD가 아니냐고 하는 개발자도 있었다. TDD라는게 뭔가 자동화 테스트와 관련이 있는 것 같은데 자세히는 모르겠고, 막연한 뭉개구름 같은 감각적 느낌으로만 알고 있는 개발자가 흔하게 있을 정도로 TDD는 그 이름에 비해 잘 알고 있는 사람은 별로 없다.
나 역시 처음 TDD를 배워보겠다고 TDDBE라는 유명한 책을 구입했었다. 책을 구매해서 고개를 끄덕끄덕 하며 감탄하며 읽었는데, 다 읽고 난 후에 현실로 돌아왔을 때 남은 것은 막연함 뿐이었다.
사실 그 때는 잘 몰랐지만 지금 와서 생각해보니 TDD를 제대로 익히기 어려운 이유가 있었는데 그건 TDD가 여러 기술을 요구하기 때문이다.
TDD를 위해 필요한 기술
Testing
테스트를 만들어야 하니까 결국 어떤 것을 테스트할 것인지에 대한 정의가 중요하다. 안타깝게도 많은 개발자들은 테스팅 기술을 익힐 수 있는 기회가 없다. 누군가 알려준적도 없을 뿐더러 QA(라고 쓰고 테스터라고 부르는)담당자가 별도로 있는 경우가 많기 때문이다. 그래서 대충대충 빠르게 만들고 테스트는 QA 혹은 사용자에게 미루다보니 스스로 테스팅을 잘 하고 익힐 수 있는 기회가 없다.
Test Automation
TDD에서의 테스트 수행 방식은 테스트 코드를 이용한 테스트 자동화를 의미한다. JUnit이나 RSpec 같은 Testing Framework를 주로 이용한다. 많은 개발자들은 TDD에서 이 부분이 가장 어려울 것이라고 생각하지만 실질적으로는 무엇을 테스트해야할지를 어려워하는 경우가 더 많다.
Refactoring
TDD의 개발 Cycle 중 필수요소로 들어가는 것이 Refactoring이다. Refactroing은 기존의 동작을 변경하지 많으면서 효율적인 코드로 개선하는 작업이다. Refactoring을 하려면 Refactoring을 하기 앞서 어떤 코드가 좋은 코드인가에 대한 기반지식이 뒷받침되어야 한다.
TDD를 배우기 어려운 이유
위의 3가지 중에 하나라도 어렵게 느껴지는 것이 있는가? TDD를 잘 하려면 위의 3가지를 기본적으로 할 수 있어야한다.
인지 부하 이론에 의하면 일반적으로 과제 해결에 요구되는 인지자원의 양이 인지구조가 보유하고 있는 자원의 용량을 초과할 때 인지과부하(cognitive overload)가 발생한다고 하는데 이는 학습 부진의 주요 원인으로 본다. 쉽게 말하면 우리가 어떤 것을 배우거나 문제를 해결할 때 필요한 기반지식이 충분히 뒷받침 되지 않으면 많은 어려움을 겪게 된다는 뜻이다.
TDD는 위의 3가지 기술을 기반으로 설계와 개발을 어떤 식으로 할 것에 대한 개발 방법론인데 기본적인 기술에 대한 이해가 없는 상황에서 TDD를 시도하게 되면 결국 인지과부하가 발생될 수밖에 없게되고 결국 TDD 적용에 실패하게 된다.
TDD를 안할지언정 정신 승리는 하지말자
간혹 테스트 코드를 짜냐는 질문에 자긴 TDD를 좋아하지 않는다고 답하는 개발자들을 보고는 한다. 그들이 내세우는 근거는 대부분 테스트 코드는 짜는데 시간이 많이 걸려서 효율이 좋지 않다는 것과 TDD는 죽었다 - 번역의 내용을 인용하는 것이다. 여기서 문제는 보통 이런 주장을 하는 사람들의 대부분은 테스트 자동화와 TDD를 구분하지 못할 뿐더러, 당연히 제대로 테스트 코드를 짜보거나 TDD를 경험해보지 못했다는 것이다. 사실 ‘TDD는 죽었다’라는 글을 쓴 DHH 는 테스트 자체를 반대한 것은 아니다.
완벽한 기술이란 없다. 하지만 본인이 지금 못한다고 해서 무조건적인 비하는 하지말자. TDD를 못한다고 볼품없는 개발자가 되는 것도 아니다. 하지만 배우기도 전에 거부하는 것은 스스로 배움의 기회를 멀리 차버리는 것과 같다.
TDD를 꼭 배우고 싶은데 그럼 어떻게 하면 좋을까?
어쩃든 여러분이 TDD를 배우기 어렵다는 것은 잘 알았다. 그럼 어떻게 TDD를 익혀나갈 수 있을 것인가? 가장 쉽고 빠른 방법은 TDD를 이미 잘 이해하고 사용하는 개발자에게 배우는 것이다. 페어 프로그래밍을 할 수 있으면 금상첨화다. 여러분 주위에 그런 사람이 있으면 그건 정말 큰 행운이라고 생각한다.
하지만 불행하게도(일반적으로) 주위에 그런 개발자가 없다면 결국 혼자 익히는 수밖에는 없다. 솔직히 필자는 TDD를 처음 접할 때 테스트 코드라는게 무엇인지도 전혀 이해를 못했다. 그럼에도 TDD를 개발에 적용할 수 있었는데 오히려 무지했기에 가능한 방법이었던 것 같다. 필자가 TDD를 어떤 방식으로 활용했고 배웠는지 궁금한가? 나는 무슨 방법을 써서라도 TDD를 익혀보고 싶다면 필자의 방법을 참고해보도록 하라.
다음 포스팅을 통해 필자가 익힌 邪派의 기술을 전수해주겠다.

당신이 TDD에 실패하는 이유

댓글