<div id="readability-page-1" class="page"><div>[번역] UnitTest By Martin Fowler마틴 파울러님의 유닛테스트 번역글입니다.최근에 테스트에 관한 관심이 많아졌습니다. 앞으로도 한동안은 테스트와 관련된 주제를 번역하거나 포스팅 할 예정입니다원문 링크: <a href="https://martinfowler.com/bliki/UnitTest.html" rel="noopener nofollow">https://martinfowler.com/bliki/UnitTest.html</a>Martin Fowler 2014 05월유닛테스트는 소프트웨어 개발에서 자주 언급되고 프로그램을 작성하는 동안 굉장히 친숙한 용어다.하지만 다른 소프트웨어 개발 용어들과 마찬가지로 정의가 잘되어 있지 않고 많은 사람들이 유닛테스트의 정의가 실제 보다 더 엄격하게 정의되어 있다고 생각하면서 혼란에 빠지곤 한다.<figure><div role="button" tabindex="0"><img alt="" src="https://miro.medium.com/max/1292/0*bP7zk5vaYmCqDFxb.png" width="646" height="506" sizes="646px" role="presentation" data-old-src="https://miro.medium.com/max/60/0*bP7zk5vaYmCqDFxb.png?q=20"></div></figure>수많은 유닛테스트를 작성해왔지만 확실하게 생각하게 된 건 Kent Beck 과 함께 일하면서 xUnit 을 사용할 때였다. (그래서 가끔 이런 종류의 테스트를 부를때 xUnit 테스트가 적당할 수도 있다고 생각한다.) *역자 Kent Beck: JUnit의 창시자중 한명 XUnit: JUnit을 시작으로 각 언어 별로 나오게 된 테스트 툴유닛테스트는 <a href="https://martinfowler.com/bliki/ExtremeProgramming.html" rel="noopener nofollow">익스트림 프로그래밍</a>의 특징적인 활동이 되었고 <a href="https://martinfowler.com/bliki/TestDrivenDevelopment.html" rel="noopener nofollow">테스트 주도 개발</a>을 빠르게 이끌었다.XP가 유닛 테스트를 사용하기 시작할 때 유닛테스트의 정의에 대한 많은 논란이 있었다.이에 관해 usenet 토론 그룹에서 많은 테스트 전문가들로부터 XPer들이 유닛테스트에 대한 정의를 잘못내리고 있다는 비판을 받았던 기억이 있다. 그래서 그에게 유닛테스트의 정의에 대해 물어봤는데 그는 “아침 트레이닝 코스에서 유닛테스트에 대한 24가지 다른 정의를 다루었다”는 식의 답변을 남겼다.이런 다양성을 떠나서, 일부 공통점들이 있다.첫번째 유닛테스트는 소프트웨어 시스템의 작은 부분들에 집중하는 로우 레벨이다.두번째 유닛테스트는 최근들어 언어별로 약간의 차이가 있는 것 말고는 크게 다르지 않은 일반적인 테스트 툴을 사용해서 프로그래머들이 직접 작성한다.*최근 이라고 표현한 이유는 분명히 XP를 통해서 어떤 변화가 만들어졌기 때문이다. 당시에 XPer들은 다른 프로그래머들이 프로그래머가 코드를 테스트 하면 안된다는 견해를 강력하게 비판했다. 일부 업체들은 개발자들이 작성한 코드에 대한 유닛 테스트를 하는 전문 테스터를 가지고 있었다. 이렇게 된 이유를 보면, 당시 사람들은 자신들의 코드를 테스트 하는 것에 대해 개념적으로 무지한(원문: blind) 상태 였다. XPer들은 프로그래머가 최소한 유닛 테스트 레벨에서 효과적인 테스터가 되는 방법을 배워야 하고 만약 다른 조직이 테스트를 대체하는 경우 테스트에 대한 피드백 루프가 절망적으로 느려질 것이라고 생각하는 관점을 가지고 있었다. 이런 상황에서 xUnit은 프로그래머들이 테스트를 작성할 때 마주치게 되는 마찰을 줄이는것에 특별히 중점을 두고 설계 되어 프로그래머가 테스트를 작성하게 되는데 중요한 역활을 수행했다.세번째 유닛테스트는 다른 테스트 방식들에 비해 확실하게 빠르기를 기대한다.이런 몇가지의 공통점들이 있지만 동시에 여러 다른 점들도 있다. 그중 한 가지는 유닛의 범위다. 객체 지향 설계에서는 클래스를 하나의 유닛으로 보지만 프로시져 또는 함수형 접근 방식에서는 하나의 함수가 유닛으로 여겨진다.하지만 이런 정의는 상황에 따라 달라질 수 있다.예를 들면 팀은 유닛의 범위를 시스템에 대한 이해와 테스트의 목적에 따라 합리적으로 규정할 수 있다.나는 처음에는 클래스 단위로 유닛을 정의하고 이후에는 밀접하게 연관된 클래스들을 하나의 유닛으로 정의하거나 가끔은 클래스 내부의 일부 메소드 만을 유닛으로 정의하기도 하지만 사실 어떻게 정의하냐는 크게 중요하지 않다.<h2 id="543b">단독(Solitary) VS 협동(Sociable)</h2>*Jay Feilds가 <a href="https://leanpub.com/wewut" rel="noopener nofollow">Working Effectively With Unit Tests</a> 라는 책에서 단독(solitary)과 협동(sociable)이라는 용어를 사용했다.유닛을 정할 때 좀 더 중요한 부분은 테스트를 진행할때 단독으로 진행할지 또는 협동적으로 진행할지 정의하는데 있다.예를 들어보자.주문 함수의 계산 메소드를 테스트를 하려고 한다. 계산 메소드는 상품이나 고객 클래스의 일부 함수들을 사용하게 된다. 만약 유닛테스트를 단독으로 진행하려고 하면, 고객이나 상품 클래스가 가지는 문제로 테스트가 실패하기를 원하지 않기 때문에 진짜 클래스를 사용하지 않는다.대신에 <a href="https://martinfowler.com/bliki/TestDouble.html" rel="noopener nofollow">테스트더블</a>을 사용해 대체할 수 있다. *역자 TestDouble 은 Mock/Stub/Fake등은 실제가 아닌 가짜로 대체하는 것을 의미한다. xUnit Test 패턴 책에서 소개되었다. 한국어판에서는 테스트 대역이라는 용어로 사용되었다.<figure><div role="button" tabindex="0"><img alt="" src="https://miro.medium.com/max/2760/0*gGX7GRRnjO9c_oj1.png" width="1380" height="386" sizes="700px" role="presentation" data-old-src="https://miro.medium.com/max/60/0*gGX7GRRnjO9c_oj1.png?q=20"></div></figure>하지만 모든 유닛테스트 사용자들이 단독 유닛 테스트를 하는건 아니다.90년대 xunit 테스트가 시작됐을 당시에는 외부 카드사 인증 시스템에 의존성을 띄는등 협동 테스트가 어렵거나 이상한 경우가 아니면 굳이 단독 테스트를 하지는 않았다.왜냐하면 가까운 테스트가 실패하더라도 실제 오류를 추적하는 작업이 어렵지 않았기 때문이다.그래서 협동 테스트를 허용하는게 실제로 문제를 만들지는 않는다고 느꼈다.사실 협동 유닛테스트를 진행하는게 Xper들이 유닛테스트라는 용어를 사용하는 것에 대한 비판중 하나였다.나는 이런 부류의 테스트가 한 가지 유닛의 행동을 테스트 한다는 점에서 유닛테스트라는 용어가 적합하다고 생각한다.우리는 테스트를 해당 유닛 외의 모든 부분이 정상적으로 동작한다는 가정하에 테스트를 작성했다.2000년대에 들어서면서 xUnit은 더 보편화되었고 단독 테스트의 개념이 적어도 일부 사람들에게 다시 돌아왔다.당시 우리는 mock객체와 mocking을 지원하는 프레임워크들이 대두되는 것을 볼 수 있었다.이런 현상에 따라서 내가 <a href="https://martinfowler.com/articles/mocksArentStubs.html" rel="noopener nofollow">클래식 스타일과 mock스타일(mockist)</a>이라고 부르는 두가지 방향이 발전되었다.두 스타일의 차이점중에 하나는 mock스타일을 추구하는 사람들은 단독 유닛테스트를 고집하고 반면에 클래식 스타일을 추가하는 사람들은 협동 유닛 테스트를 추구한다는 점이다.나는 현재 두가지 스타일 모두를 존중한다.( 개인적으로는 클래식 스타일을 좋아한다.)물론 나처럼 클래식 테스트를 좋아하는 사람도 협동 유닛 테스트가 어색한 상황에서는 테스트더블을 사용한다.원격 서비스와 통신할 때는<a href="https://martinfowler.com/articles/nonDeterminism.html#RemoteServices" rel="noopener nofollow"> 비결정성을 제거하는건</a> 충분히 가치가 있기 때문이다.그래서 일부 클래식 스타일 사용자들은 비결정성 리스크와 속도 문제를 근거로 데이터베이스, 파일시스템등 모든 종류의 외부 서비스와 연관이 있는 경우 테스트더블을 사용해야 한다고 주장한다.나는 이게 유용한 룰이라고 생각하지만 외부 리소스와 연관된 테스트를 진행할 때 테스트더블을 사용하는게 절대적인 규칙이라고 생각하지 않는다.외부 리소스와 통신이 충분히 안정적이고 빠르다면 유닛테스트에 포함하지 않을 이유가 없다.<h2 id="5e18">속도</h2>유닛 테스트의 작은 범위, 프로그래머가 직접하는 테스트, 빠른 속도와 같은 일반적인 속성들은 프로그래밍을 할 때 굉장히 자주 실행한다는 의미다.그래서 유닛테스트는 <a href="https://martinfowler.com/bliki/SelfTestingCode.html" rel="noopener nofollow">자체 테스트 코드</a>의 중요한 형질중 하나이다.이런 경우 프로그래머는 코드를 변경할 때 마다 테스트를 실행한다.나도 컴파일할 가치가 있는 코드를 작성 했을때 분단위로 테스트를 실행 할 수 도있다.내가 이렇게 하는 이유는 어쩌다 무언가를 망가뜨릴 수 있고 어떤 방식이 올바른지 알고싶기 때문이다.만약에 마지막으로 코드를 변경한뒤에 결함이 생긴다면 많은 변경사항을 찾아볼 필요가 없어 한층 더 쉽게 버그가 발생되는 지점을 찾을 수 있다. 유닛 테스트를 자주 실행하게 되는 경우 모든 유닛테스트를 실행하지는 않을 것이다. 일반적으로 현재 작업하고 있는 코드에 영향을 받는 테스트만 실행한다.언제나 테스트를 하는데 걸리는 시간과 테스트 심도간의 균형을 맞추려고 하는데, 나는 이런 스위트의 테스트를 컴파일을 할 때마다 실행되기 때문에 컴파일 스위트(compile suit) 라고 부른다. (루비와 같은 인터프리터 언어도 마찬가지다)지속적인 통합을 사용하는 경우테스트 스위트를 지속적인 통합의 한 부분으로 사용하게된다. 이런 스위트는 모든 유닛테스트를 실행한다. 나는 이걸 커밋 스위트라고 부른다. 물론 일부 <a href="https://martinfowler.com/bliki/BroadStackTest.html" rel="noopener nofollow">broad stack test</a>(end to end test라고 부르기도 한다)를 포함할 수도 있다.프로그래머는 이런 커밋 스위트를 하루에 몇번씩 실행해야 하고 명확하게는 버젼 관리 시스템에 커밋을 올리기전에 실행해야 한다. 하지만 다른 시간에도 기회가 있다. 예를들면 잠시 쉬거나 미팅에 가는 경우에 실행 할 수도 있다. 커밋 스위트가 빨라질수록 더 자주 실행할 수 있다. * 커밋 스위트를 통과하는데 걸리는 적정 시간보다 오래 걸리지만 유용한 테스트가 있다면 <a href="https://martinfowler.com/bliki/DeploymentPipeline.html" rel="noopener nofollow">배포 파이프라인</a>을 만들고 느린 테스트를 파이프라인의 마지막에 배치하자.각기 다른 사람들이 유닛테스트와 테스트 스위트의 속도에 대해 서로 다른 기준을 가지고 있다.<a href="http://david.heinemeierhansson.com/2014/slow-database-test-fallacy.html" rel="noopener nofollow">David Heinemeier Hansson</a>은 몇초 이내에 실행되는 컴파일 스위트와 몇분 이내에 실행되는 커밋스위트를 좋아한다.<a href="https://www.destroyallsoftware.com/blog/2014/tdd-straw-men-and-rhetoric" rel="noopener nofollow">Gary Bernhardt</a>는 느린것을 혐호해서인지 약 300ms가 걸리는 컴파일 스위트를 주장하고 <a href="http://dan.bodar.com/2012/02/28/crazy-fast-build-times-or-when-10-seconds-starts-to-make-you-nervous/" rel="noopener nofollow">Dan Bodart</a>는 커밋 스위트가 10초가 넘지 않기를 바란다. 나는 여기에 절대적인 답은 없다고 생각한다. 개인적으로 1초 또는 몇초가 걸리는 컴파일 스위트의 차이점을 알지 못하지만 개인적으로 Kent Beck의 규칙인 커밋 스위트의 실행시간이 10분을 넘으면 안된다는 규칙을 좋아한다.이런 여러 주장이 있지만 정말 중요한 점은 테스트 스위트를 자주 실행하는데 불편을 느끼지 않을 정도로 빠르게 하는 것이다.그리고 테스트 스위트를 충분히 자주 실행하게 되면 버그가 발생하고 문제점을 찾을 때 충분히 빠르게 문제점을 파악할 수 있는 작은 단위의 작업 범위를 가지게 된다.End<h2 id="2005">역자의 말</h2>우선 오늘도 읽어 주셔서 감사합니다. 최근에 테스트에 대한 관심이 늘면서 마틴 파울러, 켄트 벡 등 TDD와 TEST들에 관련된 분들의 글을 많이 보게 됩니다. 언제나 좋은 번역주제가 있으면 말씀 부탁드립니다.</div></div>

Stories by Jooho Son on Medium

[번역] UnitTest By Martin Fowler
마틴 파울러님의 유닛테스트 번역글입니다.
최근에 테스트에 관한 관심이 많아졌습니다. 
앞으로도 한동안은 테스트와 관련된 주제를 번역하거나 포스팅 할 예정입니다
원문 링크: https://martinfowler.com/bliki/UnitTest.html
UnitTest
Martin Fowler 2014 05월
유닛테스트는 소프트웨어 개발에서 자주 언급되고 프로그램을 작성하는 동안 굉장히 친숙한 용어다.
하지만 다른 소프트웨어 개발 용어들과 마찬가지로 정의가 잘되어 있지 않고 많은 사람들이 유닛테스트의 정의가 실제 보다 더 엄격하게 정의되어 있다고 생각하면서 혼란에 빠지곤 한다.
수많은 유닛테스트를 작성해왔지만 확실하게 생각하게 된 건 Kent Beck 과 함께 일하면서 xUnit 을 사용할 때였다.
(그래서 가끔 이런 종류의 테스트를 부를때 xUnit 테스트가 적당할 수도 있다고 생각한다.)
*역자
Kent Beck: JUnit의 창시자중 한명
XUnit: JUnit을 시작으로 각 언어 별로 나오게 된 테스트 툴
유닛테스트는 익스트림 프로그래밍의 특징적인 활동이 되었고 테스트 주도 개발을 빠르게 이끌었다.
XP가 유닛 테스트를 사용하기 시작할 때 유닛테스트의 정의에 대한 많은 논란이 있었다.
이에 관해 usenet 토론 그룹에서 많은 테스트 전문가들로부터 XPer들이 유닛테스트에 대한 정의를 잘못내리고 있다는 비판을 받았던 기억이 있다.
그래서 그에게 유닛테스트의 정의에 대해 물어봤는데 그는 “아침 트레이닝 코스에서 유닛테스트에 대한 24가지 다른 정의를 다루었다”는 식의 답변을 남겼다.
이런 다양성을 떠나서, 일부 공통점들이 있다.
첫번째
유닛테스트는 소프트웨어 시스템의 작은 부분들에 집중하는 로우 레벨이다.
두번째
유닛테스트는 최근들어 언어별로 약간의 차이가 있는 것 말고는 
크게 다르지 않은 일반적인 테스트 툴을 사용해서 프로그래머들이 직접 작성한다.
*최근 이라고 표현한 이유는 분명히 XP를 통해서 어떤 변화가 만들어졌기 때문이다.
당시에 XPer들은 다른 프로그래머들이 프로그래머가 코드를 테스트 하면 안된다는 견해를 강력하게 비판했다.
일부 업체들은 개발자들이 작성한 코드에 대한 유닛 테스트를 하는 전문 테스터를 가지고 있었다.
이렇게 된 이유를 보면, 당시 사람들은 자신들의 코드를 테스트 하는 것에 대해 개념적으로 무지한(원문: blind) 상태 였다.
XPer들은 프로그래머가 최소한 유닛 테스트 레벨에서 효과적인 테스터가 되는 방법을 배워야 하고 만약 다른 조직이 테스트를 대체하는 경우 테스트에 대한 피드백 루프가 절망적으로 느려질 것이라고 생각하는 관점을 가지고 있었다.
이런 상황에서 xUnit은 프로그래머들이 테스트를 작성할 때 마주치게 되는 마찰을 줄이는것에 특별히 중점을 두고 설계 되어 프로그래머가 테스트를 작성하게 되는데 중요한 역활을 수행했다.
세번째
유닛테스트는 다른 테스트 방식들에 비해 확실하게 빠르기를 기대한다.
이런 몇가지의 공통점들이 있지만 동시에 여러 다른 점들도 있다.
그중 한 가지는 유닛의 범위다.
객체 지향 설계에서는 클래스를 하나의 유닛으로 보지만 프로시져 또는 함수형 접근 방식에서는 하나의 함수가 유닛으로 여겨진다.
하지만 이런 정의는 상황에 따라 달라질 수 있다.
예를 들면 팀은 유닛의 범위를 시스템에 대한 이해와 테스트의 목적에 따라 합리적으로 규정할 수 있다.
나는 처음에는 클래스 단위로 유닛을 정의하고 이후에는 밀접하게 연관된 클래스들을 하나의 유닛으로 정의하거나 
가끔은 클래스 내부의 일부 메소드 만을 유닛으로 정의하기도 하지만
사실 어떻게 정의하냐는 크게 중요하지 않다.
단독(Solitary) VS 협동(Sociable)
*Jay Feilds가 Working Effectively With Unit Tests 라는 책에서 단독(solitary)과 협동(sociable)이라는 용어를 사용했다.
유닛을 정할 때 좀 더 중요한 부분은 테스트를 진행할때 단독으로 진행할지 또는 협동적으로 진행할지 정의하는데 있다.
예를 들어보자.
주문 함수의 계산 메소드를 테스트를 하려고 한다.
계산 메소드는 상품이나 고객 클래스의 일부 함수들을 사용하게 된다.
만약 유닛테스트를 단독으로 진행하려고 하면, 고객이나 상품 클래스가 가지는 문제로 테스트가 실패하기를 원하지 않기 때문에 진짜 클래스를 사용하지 않는다.
대신에 테스트더블을 사용해 대체할 수 있다.
*역자
TestDouble 은 Mock/Stub/Fake등은 실제가 아닌 가짜로 대체하는 것을 의미한다. xUnit Test 패턴 책에서 소개되었다.
한국어판에서는 테스트 대역이라는 용어로 사용되었다.
하지만 모든 유닛테스트 사용자들이 단독 유닛 테스트를 하는건 아니다.
90년대 xunit 테스트가 시작됐을 당시에는 외부 카드사 인증 시스템에 의존성을 띄는등 협동 테스트가 어렵거나 이상한 경우가 아니면 굳이 단독 테스트를 하지는 않았다.
왜냐하면 가까운 테스트가 실패하더라도 실제 오류를 추적하는 작업이 어렵지 않았기 때문이다.
그래서 협동 테스트를 허용하는게 실제로 문제를 만들지는 않는다고 느꼈다.
사실 협동 유닛테스트를 진행하는게 Xper들이 유닛테스트라는 용어를 사용하는 것에 대한 비판중 하나였다.
나는 이런 부류의 테스트가 한 가지 유닛의 행동을 테스트 한다는 점에서 유닛테스트라는 용어가 적합하다고 생각한다.
우리는 테스트를 해당 유닛 외의 모든 부분이 정상적으로 동작한다는 가정하에 테스트를 작성했다.
2000년대에 들어서면서 xUnit은 더 보편화되었고 단독 테스트의 개념이 적어도 일부 사람들에게 다시 돌아왔다.
당시 우리는 mock객체와 mocking을 지원하는 프레임워크들이 대두되는 것을 볼 수 있었다.
이런 현상에 따라서 내가 클래식 스타일과 mock스타일(mockist)이라고 부르는 두가지 방향이 발전되었다.
두 스타일의 차이점중에 하나는 mock스타일을 추구하는 사람들은 단독 유닛테스트를 고집하고 반면에 클래식 스타일을 추가하는 사람들은 협동 유닛 테스트를 추구한다는 점이다.
나는 현재 두가지 스타일 모두를 존중한다.( 개인적으로는 클래식 스타일을 좋아한다.)
물론 나처럼 클래식 테스트를 좋아하는 사람도 협동 유닛 테스트가 어색한 상황에서는 테스트더블을 사용한다.
원격 서비스와 통신할 때는 비결정성을 제거하는건 충분히 가치가 있기 때문이다.
그래서 일부 클래식 스타일 사용자들은 비결정성 리스크와 속도 문제를 근거로 데이터베이스, 파일시스템등 모든 종류의 외부 서비스와 연관이 있는 경우 테스트더블을 사용해야 한다고 주장한다.
나는 이게 유용한 룰이라고 생각하지만 외부 리소스와 연관된 테스트를 진행할 때 테스트더블을 사용하는게 절대적인 규칙이라고 생각하지 않는다.
외부 리소스와 통신이 충분히 안정적이고 빠르다면 유닛테스트에 포함하지 않을 이유가 없다.
속도
유닛 테스트의 작은 범위, 프로그래머가 직접하는 테스트, 빠른 속도와 같은 일반적인 속성들은 프로그래밍을 할 때 굉장히 자주 실행한다는 의미다.
그래서 유닛테스트는 자체 테스트 코드의 중요한 형질중 하나이다.
이런 경우 프로그래머는 코드를 변경할 때 마다 테스트를 실행한다.
나도 컴파일할 가치가 있는 코드를 작성 했을때 분단위로 테스트를 실행 할 수 도있다.
내가 이렇게 하는 이유는 어쩌다 무언가를 망가뜨릴 수 있고 어떤 방식이 올바른지 알고싶기 때문이다.
만약에 마지막으로 코드를 변경한뒤에 결함이 생긴다면 
많은 변경사항을 찾아볼 필요가 없어 한층 더 쉽게 버그가 발생되는 지점을 찾을 수 있다.
유닛 테스트를 자주 실행하게 되는 경우 모든 유닛테스트를 실행하지는 않을 것이다.
일반적으로 현재 작업하고 있는 코드에 영향을 받는 테스트만 실행한다.
언제나 테스트를 하는데 걸리는 시간과 테스트 심도간의 균형을 맞추려고 하는데, 나는 이런 스위트의 테스트를 컴파일을 할 때마다 실행되기 때문에 컴파일 스위트(compile suit) 라고 부른다.
(루비와 같은 인터프리터 언어도 마찬가지다)
지속적인 통합을 사용하는 경우테스트 스위트를 지속적인 통합의 한 부분으로 사용하게된다.
이런 스위트는 모든 유닛테스트를 실행한다. 나는 이걸 커밋 스위트라고 부른다.
물론 일부 broad stack test(end to end test라고 부르기도 한다)를 포함할 수도 있다.
프로그래머는 이런 커밋 스위트를 하루에 몇번씩 실행해야 하고 명확하게는 버젼 관리 시스템에 커밋을 올리기전에 실행해야 한다.
하지만 다른 시간에도 기회가 있다. 예를들면 잠시 쉬거나 미팅에 가는 경우에 실행 할 수도 있다.
커밋 스위트가 빨라질수록 더 자주 실행할 수 있다.
* 커밋 스위트를 통과하는데 걸리는 적정 시간보다 오래 걸리지만 유용한 테스트가 있다면 배포 파이프라인을 만들고 느린 테스트를 파이프라인의 마지막에 배치하자.
각기 다른 사람들이 유닛테스트와 테스트 스위트의 속도에 대해 서로 다른 기준을 가지고 있다.
David Heinemeier Hansson은 몇초 이내에 실행되는 컴파일 스위트와 몇분 이내에 실행되는 커밋스위트를 좋아한다.
Gary Bernhardt는 느린것을 혐호해서인지 약 300ms가 걸리는 컴파일 스위트를 주장하고 Dan Bodart는 커밋 스위트가 10초가 넘지 않기를 바란다.
나는 여기에 절대적인 답은 없다고 생각한다.
개인적으로 1초 또는 몇초가 걸리는 컴파일 스위트의 차이점을 알지 못하지만 개인적으로
Kent Beck의 규칙인 커밋 스위트의 실행시간이 10분을 넘으면 안된다는 규칙을 좋아한다.
이런 여러 주장이 있지만 정말 중요한 점은 테스트 스위트를 자주 실행하는데 불편을 느끼지 않을 정도로 빠르게 하는 것이다.
그리고 테스트 스위트를 충분히 자주 실행하게 되면 버그가 발생하고 문제점을 찾을 때 충분히 빠르게 문제점을 파악할 수 있는 작은 단위의 작업 범위를 가지게 된다.
End
역자의 말
우선 오늘도 읽어 주셔서 감사합니다. 
최근에 테스트에 대한 관심이 늘면서 마틴 파울러, 켄트 벡 등 TDD와 TEST들에 관련된 분들의 글을 많이 보게 됩니다. 
언제나 좋은 번역주제가 있으면 말씀 부탁드립니다.

[번역] UnitTest By Martin Fowler

댓글