나는 TDD에 대해 많이 썼습니다. 따라서 거의 정확한 시간에 마지막 기사를 게시했을 때 David Heinemeier Hansson은 RailsConf 기조 연설에서 TDD에 대해 언급했는데 몇 가지 질문이 있습니다.
TDD에 대한 DHH의 의견에 동의하십니까? 아직도 TDD를 추천하시나요? 그렇지 않다면 어떻게 해야 합니까?
DHH가 말한 내용
기조 연설을 놓쳤다면 DHH의 에세이가 핵심을 포착했습니다.
<블록 인용>아마도 업계의 유감스럽게도 자동화된 회귀 테스트 부족을 무너뜨리기 위해 반직관적인 램으로 테스트 우선을 사용해야 했을 것입니다. 아마도 그것은 소프트웨어 작성의 일상적인 작업에 대한 문자 그대로의 설명이 아닌 비유였을 것입니다. 그러나 그것이 무엇으로 시작되었든 그것은 곧 부패했습니다. 불신자들을 두들겨 패는 망치로 사용하여 프로답지 못하며 소프트웨어를 작성하기에 부적합하다고 선언합니다. 리트머스 테스트.
충분한. 더 이상은 없어. 제 이름은 David이고 소프트웨어 테스트를 우선적으로 작성하지 않습니다. 나는 그것을 숨기는 것이 아니라 더 이상 사과하기를 거부합니다. TDD가 자동화된 회귀 테스트에 눈을 뜨게 해 준 것에 대해 감사하지만 디자인 도그마에서 벗어난 지 오래입니다.
…
예, 테스트 우선은 나에게 죽었습니다. 하지만 무덤 위에서 춤을 추는 것보다, 나는 우스꽝스러운 것들에 머뭇거리느니 차라리 그 공헌을 존중하고 싶습니다. 그것은 우리 역사에서 중요한 단계를 기록했지만, 이제 앞으로 나아가야 할 때입니다.
전체 내용을 읽을 가치가 있지만 몇 가지 주요 요점을 정리했습니다.
- TDD는 자동 회귀 테스트를 장려하기 위한 마인드 핵입니다.
- 성난 테스트 우선 수사학은 슬픔과 절망으로 이어집니다.
- TDD는 개체 및 간접의 지나치게 복잡한 웹으로 이어집니다.
- 단위 테스트보다 격리된 시스템 테스트를 선호해야 합니다.
- 하지만 그 선호를 다른 종교로 바꾸면 안 됩니다.
- 이러한 이유로 테스트 우선은 더 이상 사용해서는 안 되는 디자인 방식이 아닙니다.
에세이에서 이러한 요점의 대부분은 함께 묶여 있습니다. 그것들은 그 자체로 의미가 있지만, 예상만큼 얽혀 있지는 않습니다.
분리하지 않으면 한 가지 주장을 하면 실제로 동의하지 않을 수도 있는 다른 주장이 가정됩니다. 여기에 트위터의 분노와 140자 제한이 결합되면 혼란, 사기꾼 및 화염 전쟁으로 끝납니다.
대신 이 몇 가지 사항에 대해 별도로 이야기하겠습니다.
TDD는 개체 및 간접의 지나치게 복잡한 웹으로 이어집니다.
최근에 Ruby 테스트 커뮤니티에서 "객체와 간접 참조의 복잡한 웹"을 선호하는 것을 보았습니다. 나는 이것이 나쁜 일이라고 생각한다. (제가 원래 Java에서 실행한 이유 중 하나입니다!) 하지만 TDD가 원인이라는 데 동의하지 않습니다.
거의 10년 동안 TDD를 수행했으며 데이터베이스에서 테스트를 분리하지 않습니다. 컨트롤러 수준 기능 테스트와 강력한 통합 테스트 도구 모음은 실행 속도에 상관없이 전체 테스트 도구 모음의 중요한 부분입니다.
시스템에서 테스트를 분리하는 것은 최적화일 뿐입니다. 그리고 YAGNI는 아직 그렇게 중요하지 않다고 말합니다. 게다가, 개별 테스트를 최적화하는 대신 SSD와 앱 사전 로드를 통해 전반적인 속도 향상을 얻고 싶습니다.
즉, TDD는 여전히 시스템 설계에 영향을 미칩니다.
TDD는 코드를 유기적으로 성장시킵니다. 이것은 좋은 일이 될 수 있습니다! 그러나 때로는 숙련된 소프트웨어 개발자가 TDD가 설계한 것보다 더 나은 코드를 작성할 수 있습니다. 다른 코드와 더 밀접하게 결합될 수 있고 모든 OOD 규칙을 따르지 않을 수 있지만 명확하고 간단하며 간단합니다. (DHH Ping Pong에는 몇 가지 좋은 예가 있습니다).
TDD는 또한 당신이 무엇을 만들고 있는지 정말로 알기 전에 객체 API 디자인에 당신을 가둘 수 있습니다. 나중에 API를 변경하기 어렵게 만듭니다. 그리고 그 마찰로 인해 더 나쁜 디자인에 안주할 수 있습니다.
테스트 우선은 더 이상 사용해야 하는 디자인 방식이 아닙니다.
TDD는 유연하고 잘 테스트된 코드를 만들기 위한 훌륭한 도구입니다. 그래서 저는 이 점에 전적으로 동의하지 않습니다. 이전 기사에서 이미 TDD의 많은 이점에 대해 이야기했습니다.
<블록 인용>- 보다 유연하고 테스트를 거친 개체 모델을 사용하게 될 것입니다.
- 시스템은 기본적으로 테스트 가능하므로 향후 테스트 작성 비용을 절감할 수 있습니다.
- 개발 프로세스 전반에 걸쳐 테스트 비용을 상각하여 추정치를 더 정확하게 만듭니다.
- 다음에 무엇을 할지 결정할 필요가 없기 때문에 흐름을 유지합니다.
이러한 이점 외에도 연습하는 데 도움이 됩니다. 테스트. 항상 테스트를 먼저 작성하기 때문에 테스트를 많이 할 것입니다. 사실 이후에 테스트를 시도한 경우보다 . 테스트가 실제로 올바른지 즉시 알 수 있습니다(먼저 실패할 것이기 때문에). 또한 "이번 한 번" 테스트를 건너뛸 변명의 여지가 없습니다.
화난 테스트 우선 수사는 슬픔과 절망으로 이어집니다.
전적으로, 100% 동의합니다. 네 이렇게 또 올립니다. 그러나 누군가가 이점에 대해 알지 못하거나 아직 수행하는 방법을 제대로 배우지 못했기 때문에 TDD를 하지 않거나 TDD를 사용하는 것이 불편하다고 느끼는 경우 올바른 접근 방식은 그들을 부끄럽게 하지 않는 것입니다. 도와 TDD가 유용하다면 어떻게 도움이 되는지 보여주십시오. 관심이 있다면 시작할 수 있도록 도와주세요.
TDD가 없는 코드가 표시되는 방식을 선호하기 때문에 TDD를 수행하지 않는다면 그대로 두십시오.
전문 지식을 쌓으면서 자신의 직관, 취향, 선호하는 소프트웨어 개발 기술을 개발하게 됩니다. 그리고 어떤 인터넷 논쟁도 전문가에게 그런 것들을 무시하도록 가르치지 않을 것입니다.
따라서 모범 사례에 대한 아이디어를 따르지 않는 사람을 비판하려는 경우 학습 능력을 손상시키거나 소리를 지르며 무의미하게 만듭니다. 이것은 최선의 경우 시간 낭비이며 최악의 경우 귀하의 대의에 해를 끼치는 것입니다.
그래서 TDD를 유지해야 합니까?
네! 배우고 연습하는 것이 좋습니다.
테스트 방법을 가르쳐준 TDD를 인정하고 TDD를 할 때 여전히 큰 이점을 얻습니다. 완벽하지는 않지만 마법처럼 더 나은 코드를 생성하는 열쇠는 하나의 기술이 아닙니다.
대신 새로운 패턴, 기술 및 도구를 계속 배워야 합니다. 올바른 느낌이 있기 때문에 올바른 위치에 올바른 패턴을 사용할 수 있을 때까지 적용하는 연습을 하세요. .
배우면서 시간을 내어 코드를 수정하고, 리팩토링하고, 실험해 보십시오. 이전 코드와 새 코드를 살펴보십시오. 당신보다 경험이 많은 사람에게 검토를 요청하십시오. 더 잘 만들었나요? 이렇게 하면 성장합니다.