<div id="readability-page-1" class="page"><div><div><a rel="noopener" href="/@joohotheman?source=post_page-----2d81c1437ac--------------------------------"><div><img alt="Jooho Son" src="https://miro.medium.com/fit/c/56/56/1*BqZBgi0ioK3W2zU4oV0GYQ.jpeg" width="28" height="28"></div></a></div>안녕하세요 2년차 개발자 손주호입니다.오늘의 글은 마틴 파울러님의 SelfTestingCode를 번역한 글입니다.원문: <a href="https://martinfowler.com/bliki/SelfTestingCode.html" rel="noopener nofollow">https://martinfowler.com/bliki/SelfTestingCode.html</a>앞으로도 가끔식 번역을 올리게 될 것같습니다.비문 또는 문제점이 있는 번역에 대한 지적은 항상 감사합니다.<h2 id="4e06">Self-Testing Code (자체 테스트 코드)</h2>자체 테스트 코드(Self-Testing Code)는 동작중인 소프트웨어에 포괄적인 자동 테스트 작성을 결합하기 위한 예제를 표현하고자 리팩토링 책에서 사용한 이름이다.자체 테스트 코드는 잘 작성한다면 하나의 커맨드를 통해 모든 테스트를 실행하고 테스트를 통해 코드 속에 숨어있는 어떤 버그라도 찾을 수 있다는 자신감을 가질 수 있다.이런 생각을 처음하게 된 계기는 OOPSLA (Object-Oriented Programming, Systems, Languaged &amp; Applications, 매년 열리는 ACM 컨퍼런스) 에서 Dave Thomas(미국의 기업인 / 웬디스 창업자)가 모든 객체는 스스로 테스트 가능해야 한다는 발언이었다.그 얘기를 듣고 커맨드를 입력하면 하드웨어 부팅때 메모리를 테스트 하는 것과 유사하게 전체 소프트웨어 시스템이 자체 테스트를 하는 비전이 생각났다.얼마 후 프로젝트에서 이런 접근 방식을 파고들어 봤고 자체 테스트가 주는 장점을 보며 행복해졌다.몇년 뒤 Kent Beck (Gang Of Four 의 일원 / Junit 창시자 / TDD 창시자 / Extreme Programming 저자 등등) 과 몇개의 작업을 같이 하게 되었다. Kent Beck은 자체 테스트를 내가 한 방식보다 한참 더 세련된 방식으로 하고 있었다.이때가 Kent Beck과 Erich Gamma가 자체 테스트와 그 사촌격인 TestDrivenDevelopement 에 대한 많은 시도와 생각을 하게 만든 주춧돌같은 툴인 JUnit을 소개하기 얼마전이었다.코드 베이스에 대한 자체 테스트 코드를 작성하게 되면 일련의 자동화된 테스트를 실행 할 수 있고 테스트가 통과하면 코드가 오류가 결함등으로부터 자유롭다고 확신 할 수 있게 된다.이런 방식을 통해 알 수 있는건, 소프트웨어를 만드는 동시에 시스템 내부의 어떤 결함과 버그라도 찾을 수 있는 버그 디텍터를 만들게 된다.만약 팀의 누군가 어쩌다 버그를 만들게 되면, 버그 디텍터가 찾아줄 수 있게 된다.테스트를 하루에 몇번 이상 자주 실행하게 되면 버그가 생기고 얼마 안되서 알 수 있게 된다.그러면 최근에 추가한 코드만 확인해도 버그를 좀 더 빨리 찾을 수 있게 된다.어떤 프로그래밍 에피소드도 작동하는 코드와 지속적으로 작동하게 해주는 테스트를 제외하고는 완성되었다고 할 수 없다.우리는 어떤 사소한 코드라도 테스트 없이는 깨진 코드라고 추정하는 태도를 가져야 한다.자체 테스트 코드는 지속적인 통합 의 핵심요소중 하나다. (Cotinuous Intergration: <a href="https://martinfowler.com/articles/continuousIntegration.html" rel="noopener nofollow">https://martinfowler.com/articles/continuousIntegration.html</a>)그렇기 때문에 자체 테스트 코드를 작성하기 전에는 지속적인 통합을 하고있다고 말할 수 없다.자체 테스트 코드는 지속적인 통합의 한축을 담당하는동시에 지속적인 전달의 필수요소다. (Continuous Delivery: <a href="https://martinfowler.com/delivery.html" rel="noopener nofollow">https://martinfowler.com/delivery.html</a>)자체 테스트 코드는 상용 소프트웨어의 버그 숫자를 획기적으로 줄일 수 있다는 명확한 장점을 가지고 있고,이런 방식을 통해서 개발자들이 테스트와 코드를 같이 작성하는 테스팅 문화를 만들어 갈 수 있다.하지만 상용 버그를 피하는 것이 자체 테스트의 가장 큰 장점은 아니다.가장 큰 장점은 기존 시스템을 변경할 때 자신감을 가지고 변경을 하게 되는 것이다.오래된 코드들은 개발자들이 작동하고 있는 코드를 변경하는데 두려움을 느끼게 되는 공포스러운 곳이다.기존 버그를 고치면 오히려 더 많은 버그를 만들 수 있기 때문에 버그를 고치는 것마저 위험하다.이런 환경에서는 새로운 기능을 추가하고 시스템을 리팩토링하는 것이 경악스러울 정도로 느려지게 된다.시간이 지나며 기술 부채가 증가하게 되고 (Technical Debt: <a href="https://martinfowler.com/bliki/TechnicalDebt.html" rel="noopener nofollow">https://martinfowler.com/bliki/TechnicalDebt.html</a>)매번 변경을 할 때마다 사람들은 두려움을 느끼게 되고 더 많은 변경을 만드는 것을 무서워하게 되는 악순환에 빠지게 된다.자체 테스트 코드를 도입하면 조금 다른 그림이 된다.이 상황에서 사람들은 누군가 또는 자신이 실수를 하더라고 버그 디텍터가 잡아내고 빠르게 코드를 고치고 다시 이어갈 수 있기 때에 안전하게 코드를 개선하고 작은 버그들을 고칠 수 있다는 자신감을 가지게 된다.이런 안전망과 함께 하게되면 코드가 더 좋은 모습으로 남아있게 하는데 시간을 투자하고 신규 기능을 한층 더 안정적이고 빠르게 추가할 수 있는 선순한을 만들 수 있다.이런 종류의 장점들은 TDD와 함께 논의되지만, TDD는 자체 테스트 코드를 만들때 얻게 되는 장점의 한 사례라고 생각하기 때문에 TDD의 컨셉과 자체 테스트 코드는 나누어서 생각하는게 좋다.TDD는 내가 정말 좋아하는 개발 방법이고 좋은 방법이지만 코드를 작성하고 자체 테스트 코드를 작성 할 수도 있다.(역자: TDD에서는 테스트를 먼저 작성하고 점진적으로 코드를 작성하는 방법을 택하고 있습니다.)다만 테스트 코드를 작성하고 통과할 때까지는 작업이 끝난게 아니다.자체 테스트 코드에서 중요한 점은 어떻게 테스트 코드의 작성 방식이 아니라 테스트를 작성는것 자체가 중요하다.자체 테스트 코드를 학습하고 있는 팀에게 중요한 행동은 상용 버그에 대한 반응이다.일반적인 방법은 상용 버그를 재현하는 테스트를 작성하고, 버그를 해결해나가는 방법이다.이런 경우 버그를 발생시키는 부분을 찾을 때까지 조금씩 범위를 좁혀가며 단위테스트를 작성해 나가는 것이 좋다.이런 방식은 디버깅만큼 유용하고 버그가 고쳐졌고 고쳐진 상태로 이어질 수 있다고 확신할 수 있게 해준다.팀은 이 버그를 고치는 경험을 통해 비슷하게 빠진 테스트 들을 찾을 수 있는 통찰을 얻을 수도 있다.모든 버그는 코드의 버그인 동시에 테스트의 오류라는 태도를 가져야 한다.오늘날 우리는 자체 테스트의 다른 차원을 보고있고 상용 환경 모니터링에 중점을두고 있다.지속적인 전달은 상용 환경에 더 빠르게 새로운 버전을 배포할 수 있게 해준다.지속적인 전달이 구축된 환경에서 팀은 상용 환경에서 버그를 발견하면 즉각적으로 버그를 수정하고 수정 버전을 배포할 수 있거나 가장 최근의 문제가 없는 버전으로 롤백 할수 있다.이 글은 2005년 5월에 좀 더 적은 분량으로 작성됐었습니다.</div></div>

Stories by Jooho Son on Medium

안녕하세요 2년차 개발자 손주호입니다.
오늘의 글은 마틴 파울러님의 SelfTestingCode를 번역한 글입니다.
원문: https://martinfowler.com/bliki/SelfTestingCode.html
앞으로도 가끔식 번역을 올리게 될 것같습니다.
비문 또는 문제점이 있는 번역에 대한 지적은 항상 감사합니다.
Self-Testing Code (자체 테스트 코드)
자체 테스트 코드(Self-Testing Code)는 동작중인 소프트웨어에 포괄적인 자동 테스트 작성을 결합하기 위한 예제를 표현하고자 리팩토링 책에서 사용한 이름이다.
자체 테스트 코드는 잘 작성한다면 하나의 커맨드를 통해 모든 테스트를 실행하고 테스트를 통해 코드 속에 숨어있는 어떤 버그라도 찾을 수 있다는 자신감을 가질 수 있다.
이런 생각을 처음하게 된 계기는 OOPSLA
(Object-Oriented Programming, Systems, Languaged & Applications, 매년 열리는 ACM 컨퍼런스)
에서 Dave Thomas(미국의 기업인 / 웬디스 창업자)가 모든 객체는 스스로 테스트 가능해야 한다는 발언이었다.
그 얘기를 듣고 커맨드를 입력하면 하드웨어 부팅때 메모리를 테스트 하는 것과 유사하게 전체 소프트웨어 시스템이 자체 테스트를 하는 비전이 생각났다.
얼마 후 프로젝트에서 이런 접근 방식을 파고들어 봤고 자체 테스트가 주는 장점을 보며 행복해졌다.
몇년 뒤 Kent Beck
(Gang Of Four 의 일원 / Junit 창시자 / TDD 창시자 / Extreme Programming 저자 등등)
과 몇개의 작업을 같이 하게 되었다. Kent Beck은 자체 테스트를 내가 한 방식보다 한참 더 세련된 방식으로 하고 있었다.
이때가 Kent Beck과 Erich Gamma가 자체 테스트와 그 사촌격인 TestDrivenDevelopement 에 대한 많은 시도와 생각을 하게 만든 주춧돌같은 툴인 JUnit을 소개하기 얼마전이었다.
코드 베이스에 대한 자체 테스트 코드를 작성하게 되면 일련의 자동화된 테스트를 실행 할 수 있고 테스트가 통과하면 코드가 오류가 결함등으로부터 자유롭다고 확신 할 수 있게 된다.
이런 방식을 통해 알 수 있는건, 소프트웨어를 만드는 동시에 시스템 내부의 어떤 결함과 버그라도 찾을 수 있는 버그 디텍터를 만들게 된다.
만약 팀의 누군가 어쩌다 버그를 만들게 되면, 버그 디텍터가 찾아줄 수 있게 된다.
테스트를 하루에 몇번 이상 자주 실행하게 되면 버그가 생기고 얼마 안되서 알 수 있게 된다.
그러면 최근에 추가한 코드만 확인해도 버그를 좀 더 빨리 찾을 수 있게 된다.
어떤 프로그래밍 에피소드도 작동하는 코드와 지속적으로 작동하게 해주는 테스트를 제외하고는 완성되었다고 할 수 없다.
우리는 어떤 사소한 코드라도 테스트 없이는 깨진 코드라고 추정하는 태도를 가져야 한다.
자체 테스트 코드는 지속적인 통합 의 핵심요소중 하나다.
(Cotinuous Intergration: https://martinfowler.com/articles/continuousIntegration.html)
그렇기 때문에 자체 테스트 코드를 작성하기 전에는 지속적인 통합을 하고있다고 말할 수 없다.
자체 테스트 코드는 지속적인 통합의 한축을 담당하는
동시에 지속적인 전달의 필수요소다.
(Continuous Delivery: https://martinfowler.com/delivery.html)
자체 테스트 코드는 상용 소프트웨어의 버그 숫자를 획기적으로 줄일 수 있다는 명확한 장점을 가지고 있고,
이런 방식을 통해서 개발자들이 테스트와 코드를 같이 작성하는 테스팅 문화를 만들어 갈 수 있다.
하지만 상용 버그를 피하는 것이 자체 테스트의 가장 큰 장점은 아니다.
가장 큰 장점은 기존 시스템을 변경할 때 자신감을 가지고 변경을 하게 되는 것이다.
오래된 코드들은 개발자들이 작동하고 있는 코드를 변경하는데 두려움을 느끼게 되는 공포스러운 곳이다.
기존 버그를 고치면 오히려 더 많은 버그를 만들 수 있기 때문에 버그를 고치는 것마저 위험하다.
이런 환경에서는 새로운 기능을 추가하고 시스템을 리팩토링하는 것이 경악스러울 정도로 느려지게 된다.
시간이 지나며 기술 부채가 증가하게 되고
(Technical Debt: https://martinfowler.com/bliki/TechnicalDebt.html)
매번 변경을 할 때마다 사람들은 두려움을 느끼게 되고 더 많은 변경을 만드는 것을 무서워하게 되는 악순환에 빠지게 된다.
자체 테스트 코드를 도입하면 조금 다른 그림이 된다.
이 상황에서 사람들은 누군가 또는 자신이 실수를 하더라고 버그 디텍터가 잡아내고 빠르게 코드를 고치고 다시 이어갈 수 있기 때에 안전하게 코드를 개선하고 작은 버그들을 고칠 수 있다는 자신감을 가지게 된다.
이런 안전망과 함께 하게되면 코드가 더 좋은 모습으로 남아있게 하는데 시간을 투자하고 신규 기능을 한층 더 안정적이고 빠르게 추가할 수 있는 선순한을 만들 수 있다.
이런 종류의 장점들은 TDD와 함께 논의되지만, TDD는 자체 테스트 코드를 만들때 얻게 되는 장점의 한 사례라고 생각하기 때문에 TDD의 컨셉과 자체 테스트 코드는 나누어서 생각하는게 좋다.
TDD는 내가 정말 좋아하는 개발 방법이고 좋은 방법이지만 코드를 작성하고 자체 테스트 코드를 작성 할 수도 있다.
(역자: TDD에서는 테스트를 먼저 작성하고 점진적으로 코드를 작성하는 방법을 택하고 있습니다.)
다만 테스트 코드를 작성하고 통과할 때까지는 작업이 끝난게 아니다.
자체 테스트 코드에서 중요한 점은 어떻게 테스트 코드의 작성 방식이 아니라 테스트를 작성는것 자체가 중요하다.
자체 테스트 코드를 학습하고 있는 팀에게 중요한 행동은 상용 버그에 대한 반응이다.
일반적인 방법은 상용 버그를 재현하는 테스트를 작성하고, 버그를 해결해나가는 방법이다.
이런 경우 버그를 발생시키는 부분을 찾을 때까지 조금씩 범위를 좁혀가며 단위테스트를 작성해 나가는 것이 좋다.
이런 방식은 디버깅만큼 유용하고 버그가 고쳐졌고 고쳐진 상태로 이어질 수 있다고 확신할 수 있게 해준다.
팀은 이 버그를 고치는 경험을 통해 비슷하게 빠진 테스트 들을 찾을 수 있는 통찰을 얻을 수도 있다.
모든 버그는 코드의 버그인 동시에 테스트의 오류라는 태도를 가져야 한다.
오늘날 우리는 자체 테스트의 다른 차원을 보고있고 상용 환경 모니터링에 중점을두고 있다.
지속적인 전달은 상용 환경에 더 빠르게 새로운 버전을 배포할 수 있게 해준다.
지속적인 전달이 구축된 환경에서 팀은 상용 환경에서 버그를 발견하면 즉각적으로 버그를 수정하고 수정 버전을 배포할 수 있거나 가장 최근의 문제가 없는 버전으로 롤백 할수 있다.
이 글은 2005년 5월에 좀 더 적은 분량으로 작성됐었습니다.

[번역] Self-Testing Code(자체 테스트 코드)- Martin Fowler

댓글