정의 Test-Driven Development(TDD)는 동작하는 코드를 작성하기 전에 그 코드가 통과해야 할 자동화된 테스트를 먼저 작성하는 개발 방식이다. 2002년 Kent Beck의 Test-Driven Development: By Example로 정리됐고, Extreme Programming(XP)의 실천법 중 하나에서 출발했다. 이름에 “Test"가 들어 있지만 TDD는 테스트 기법이 아니라 설계 기법으로 분류된다. 테스트를 먼저 쓰려면 그 코드를 어떻게 호출할지, 무엇을 주고 무엇을 받을지를 먼저 정해야 하고, 그 결정이 곧 인터페이스 설계이기 때문이다. 테스트 스위트는 그 과정에서 부수적으로 남는 산출물에 가깝다. ...
개요 TDD로 만들어지는 테스트는 대부분 빠른 저수준 테스트다. 그런데 저수준 테스트만으로는 조립된 시스템이 동작한다는 보장이 없고, 반대로 고수준 테스트만 쌓으면 빌드가 느려지고 잘 깨진다. 어떤 종류의 테스트를 어떤 비율로 둘 것인가를 다루는 것이 테스트 피라미드다. 이 질문은 TDD 개요에서 정리한 “TDD is dead” 논쟁이 최종적으로 수렴한 지점이기도 하다. 쟁점은 TDD를 하느냐 마느냐가 아니라 테스트 포트폴리오를 어떻게 구성하느냐였다. 피라미드 핵심 주장은 한 문장이다. GUI를 통과하는 고수준 테스트보다 저수준 단위 테스트가 훨씬 많아야 한다. ...
개요 Red-Green-Refactor는 TDD의 단위 작업 루프다. 세 단계가 각각 다른 목적을 가지며, 한 번에 한 가지만 한다는 원칙이 전부다. Red 단계에서는 설계를 생각하고, Green 단계에서는 통과만 생각하고, Refactor 단계에서는 정리만 생각한다. 단계 질문 금지 사항 Red 이 코드를 어떻게 쓰고 싶은가 구현 코드를 건드리는 것 Green 어떻게 하면 가장 빨리 통과하는가 일반화, 미리 하는 설계 Refactor 무엇이 중복인가 동작 변경, 기능 추가 Robert C. Martin은 같은 루프를 세 가지 금지 규칙으로 다시 썼다. 사이클을 초 단위까지 조인 형태다. ...
정의 Self-testing Code는 명령 하나로 테스트 전체를 실행할 수 있고, 그 테스트가 통과하면 코드에 중대한 결함이 없다고 확신할 수 있는 상태를 가리킨다. Martin Fowler가 Refactoring에서 이 실천에 붙인 이름이다. Fowler가 제시하는 사고 모형은 명확하다. 소프트웨어 시스템을 만드는 동시에 그 시스템 내부의 결함을 감지하는 버그 탐지기를 함께 만든다. 팀의 누군가가 실수로 버그를 넣으면 탐지기가 울린다. 스위트를 하루에도 여러 번 돌리면 버그가 들어온 직후에 감지되므로 최근 변경분만 살펴보면 되고, 그만큼 찾기가 쉬워진다. ...
개요 TDD를 실천하는 방식은 크게 두 갈래로 나뉜다. 갈림길은 하나다. 테스트 대상이 의존하는 협력 객체를 실제 구현으로 둘 것인가, 목(mock)으로 대체할 것인가. 명칭 다른 이름 협력 객체 검증 대상 Classicist Chicago 학파, Detroit 학파, Inside-Out 가능한 한 실제 객체 상태(state) Mockist London 학파, Outside-In, Interaction 테스트 대부분 목 상호작용(interaction) 두 이름의 유래는 지역이다. Classicist는 Kent Beck과 초기 XP 커뮤니티(디트로이트의 Chrysler C3 프로젝트)에서, Mockist는 런던의 Extreme Tuesday Club에서 Steve Freeman·Nat Pryce 등이 목 객체를 정리하며 형성됐다. ...
정의 테스트 더블(Test Double)은 테스트에서 실제 협력 객체를 대신하는 모든 대역을 가리키는 총칭이다. 영화의 스턴트 더블(stunt double)에서 온 이름으로, Gerard Meszaros가 xUnit Test Patterns에서 정리했다. 대역이 필요한 이유는 협력 객체가 다음 중 하나에 해당할 때다. 아직 구현되지 않았다 실행이 느리다 (DB, 네트워크) 결과가 매번 다르다 (현재 시각, 랜덤, 외부 시세) 원하는 상태를 만들기 어렵다 (특정 예외, 네트워크 타임아웃) 호출하면 부작용이 있다 (실제 결제, 메일 발송) 일상적으로는 이 모두를 “목(mock)“이라고 뭉뚱그려 부르지만, 다섯 가지는 목적이 서로 다르고 그중 하나만 검증에 관여한다. ...