일부 코드를 테스트하고 싶지만 막혔습니다. 객체의 인터페이스가 어떻게 생겼는지 완전히 확신하지 못할 수도 있습니다. 또 다른 화창한 여름날에 정신이 산만해질 수도 있습니다. 구축하려고 생각하는 것을 테스트할 수 있는지 확신하지 못할 수도 있습니다. 아니면 지금 당장 테스트를 작성하고 싶지 않아서 미루고 있을 수도 있습니다. TDD를 하고 싶지 않을 때 TDD의 이점을 어떻게 얻나요?
시제품 제작 또는 버릴 수 있는 제작
<블록 인용>“새로운 시스템 개념이나 새로운 기술이 사용되는 곳에서는 버릴 수 있는 시스템을 구축해야 합니다. 아무리 좋은 계획이라도 처음부터 올바르게 수행할 만큼 전지전능하지 않기 때문입니다. 따라서 하나를 버릴 계획입니다. 어쨌든 그럴거야." – 프레드 브룩스
때로는 새로운 기능을 시작할 때 첫 번째 테스트를 작성해야 한다고 생각하면 마비되는 느낌이 들 때가 있습니다. API가 어떻게 보여야 하는지, 어떤 패턴과 관행이 가장 적절할지, 어떻게 함께 맞춰야 하는지에 대해 결정해야 할 사항이 너무 많습니다.
막혔을 때 시작할 수 있는 몇 가지 방법이 있습니다. 시제품을 만드는 것은 또 다른 문제입니다.
프로토타입을 작성할 때 스케치처럼 생각해야 합니다. 브레인스토밍을 하고 시도해 보세요. 아직 테스트나 TDD에 신경쓰지 마세요. 대신 코드를 사용하여 어려운 결정을 내리십시오. 몇 가지 패턴을 시도하고 디자인하려는 기능에 맞는 패턴을 확인하십시오. 앱에서 흔들리는 부분이 어디인지, 더 생각해야 할 부분이 무엇인지, 이유 없이 걱정했던 부분이 무엇인지 파악하세요.
그런 다음 버리고 다시 만드세요. 이번에는 TDD와 기능을 가장 잘 구축할 수 있는 방법에 대한 새로 발견한 지식을 사용합니다.
실수로 git checkout -f를 실행했을 때 당신이 뭔가를 쓴 후, 그리고 당신은 방금 배를 차고 있는 것 같은 느낌을 받습니까? 하지만 그러고 나면 이것은 빌드해야 하므로 다시 하게 될 것 같습니다. 처음보다 훨씬 좋아졌죠? 이것은 프로토타입을 재구축할 때도 마찬가지입니다. 이제 기능을 할 수 있는 확실한 아이디어가 생겼습니다. 이 기능을 TDD하면 훨씬 더 쉽게 진행할 수 있습니다.
역 TDD
빌드 방법은 알지만 테스트를 먼저 작성하는 방법을 모르는 상황에 처한 적이 있습니까? 아니면 방법에 대한 한 줄 변경이지만 약간의 조정이 필요할 수 있으므로 변경 사항이 실제로 어떻게 보일지 알기 전에 테스트로 잠그고 싶지 않습니까?
다음과 같은 상황에 많은 도움이 되는 간단한 절차가 있습니다.
- 테스트 없이 코드를 작성하세요.
- 코드에 대한 테스트를 작성합니다. 통과되었는지 확인하세요.
- 댓글 달기 작성한 코드를 변경하거나 코드를 변경한 파일을 되돌립니다.
- 테스트를 다시 실행합니다. 실패하는지 확인하세요.
- 코드를 다시 작성하십시오. 테스트를 실행합니다. 통과되었는지 확인하세요.
- 코드 리팩터링 , 새로운 테스트를 활용합니다.
저는 이것을 역 TDD라고 생각합니다. 또는 녹색-적색-녹색-리팩터 TDD의 "테스트 주도 설계" 부분을 얻지는 못하지만 코드가 손상되면 테스트가 실패하는 것을 볼 수 있습니다. 중요합니다. 한 번도 실패하지 않는 테스트는 신뢰할 수 없기 때문입니다.
역 TDD는 일반적으로 많은 설계가 필요하지 않은 작은 변경에서 가장 잘 작동합니다. 한 줄, 메서드 또는 클래스에 국한된 버그 수정 또는 변경 사항을 생각해 보십시오. 하지만 이 기술을 많이 사용합니다. 특히 아직 작업 중인 작은 변경 사항에 대해 그렇습니다.
페어링 게임
페어링 게임은 주변에 다른 개발자가 있을 때 Red-Green-Refactor 루틴에서 벗어날 수 있는 좋은 방법입니다. 다음과 같이 작동합니다.
- 파트너를 찾으세요.
- 당신은 실패할 테스트를 작성합니다.
- 파트너는 가능한 가장 간단한 코드로 테스트를 수정하려고 합니다.
- 해당 코드에서 실패할 다른 테스트를 작성합니다.
- 파트너가 해당 테스트를 통과할 코드를 작성합니다.
- 반복...
- 테스트가 녹색일 때 테스트를 작성하는 대신 일부 코드를 리팩터링하도록 선택할 수 있습니다.
- 리팩토링 후 테스터와 코더 위치를 바꿉니다.
비밀을 알려 드리겠습니다. 볼링 점수 계산기로 짝짓기 게임을 하는 것이 제가 원래 TDD를 배운 방법입니다. 실패한 테스트를 기반으로 간단한 코드 작성을 연습하고 이러한 테스트를 처음부터 작성하는 데 도움이 됩니다. 두 개발자는 서로의 코딩 스타일과 좋아하는 기술에 대해 많은 것을 배울 것입니다. 그리고 거의 즉시 플로우에 도달하게 되므로 완료했을 때 기분이 좋아질 것입니다.
코드를 빨리 생성할 수는 없지만 매우 재미있고 훌륭한 학습 경험입니다.
즐겁고 실험적
TDD는 도그마가 되어서는 안 됩니다. 몇 가지 정말 흥미로운 장소로 인도할 수 있는 핵심 TDD 개념을 가지고 놀 수 있는 방법이 있습니다. 그리고 더 나은 코드를 얻을 수도 있습니다.
그래서 실험합니다. 코드 및 TDD 작성에 대한 새로운 접근 방식을 시도하십시오. 그들이 당신을 어떻게 느끼게 하고 어떤 종류의 코드로 끝나는지 보십시오. 그리고 매일 하는 일의 재미와 흐름을 계속 재발견하세요.