(저는 이번 주에 RailsConf를 위해 시카고에 있습니다. 저를 만나면 인사하세요! 만나고 싶습니다. 사이드바에 있는 사진에서 제가 나이 많은 사람입니다.)
한 독자가 내 기사 중 하나에 대한 댓글에서 테스트에 대한 훌륭한 질문을 했습니다.
<블록 인용>"TDD 플라이휠"도 움직여야 한다는 것을 알고 있지만 TDD는 저에게 매우 낯설습니다. RSpec으로 시작하는 가장 좋은 방법에 대한 권장 사항이 있습니까? 아니면 "거기서 해킹"하는 것과 같은 것입니까?
그래서 나는 대답했다:
<블록 인용>둘 중 하나에 정착하지 못했다면 실제로 minitest를 시작하는 것이 더 쉽다는 것을 알게 될 것입니다. 조금 더 '메소드 및 클래스'이므로 새로운 구문을 배우지 않고도 TDD를 배우고 연습하는 데 완전히 집중할 수 있습니다.
Rails에는 테스트 용어, 주장 및 Rails에서 일반적으로 테스트를 실행하는 방법에 대한 꽤 좋은 가이드가 있습니다.
TDD를 배우는 가장 좋은 방법은 연습하는 것입니다. 따라야 할 단계는 다음과 같습니다.
- 필요한 코드가 이미 있다고 가정하는 테스트를 작성하세요.
- 테스트를 실행하고 새 테스트가 실패하는지 확인
- 테스트를 통과할 가장 간단한 코드를 작성하십시오. 여기에서 지나치게 추상화하거나 리팩토링하지 마세요.
- 테스트를 실행하고 새 테스트가 통과하는지 확인
- 코드를 리팩터링하여 중복을 제거하거나 코드를 더 표현력 있게 만드세요.
- 테스트를 다시 실행하여 여전히 통과하는지 확인합니다.
- 1단계로 돌아갑니다.
TDD를 연습하는 동안 계속 자문해야 합니다. 나는 어느 단계에 있습니까? 내가 단계를 건너 뛰었습니까? 다음 단계는 무엇입니까? (항상 이 단계 중 하나에 있어야 합니다.) 이는 올바른 방향으로 가는 데 도움이 될 것이며, 이는 정말 중요 새로운 것을 배우는 동안. "연습은 영원하다", 잘못된 것을 연습하고 싶지 않다면!
또한 혼란을 허용하세요. . 당신은 배우고 있습니다, 그것은 완전히 OK입니다! 더 자주 할수록 훨씬 쉬워집니다.
테스트에 관한 책도 집필하고 있는 Eric Steel은 제가 놓친 핵심 사항을 언급했습니다.
<블록 인용>TDD에서 뒤처지는 부분은 1단계 이전에 발생하는 계획의 양입니다.
테스트는 앱의 요구 사항이 계획된 구현을 충족하는 곳입니다. 테스트 주도 개발은 앱이 수행해야 하는 작업을 아는 데 크게 의존하며 수행 방법에 대한 아이디어가 있다고 가정합니다.
Rails로 처음 빌드를 시작할 때 우리는 많은 것을 알지 못합니다. 우리는 우리가 찾고 있는 것과 유사한 결과를 얻을 때까지 실험적인 코드를 작성하는 데 많은 시간을 할애합니다. 더 많이 배울수록 이 작업을 덜 수행합니다. 이것이 TDD가 '무엇을 만들고 있는지 파악'이 아닌 '테스트 작성'으로 시작하는 이유라고 생각합니다. 테스트할 즈음에는 많은 경험을 하게 됩니다.
'테스트 작성' 전에 다음 단계를 추가합니다.
- 요구 사항을 브레인스토밍하고 정당화하고 추려냅니다. 어떤 대가를 치르더라도 코딩을 피하세요.
- 이러한 요구 사항을 충족하는 코드를 계획하고 디자인합니다.
- 알 수 없는 질문에 답하기 위해 코드를 수정하되 해당 코드는 따로 보관하세요.
내 조언:
- 구문 이상의 계획에 집중
- 도구 최소화(minitest/fixtures가 정말 유용하다는 것을 알았습니다)
- 연습, 연습, 연습
다른 모든 것과 마찬가지로 TDD를 시작하려면 연습과 자가 수정 능력이 필요합니다(또는 주변에 수정해줄 사람이 있어야 함). 몇 가지 반강체 단계를 따르고 현재 진행 중인 단계에 대해 주의를 기울이면 TDD가 곧 완전히 자연스럽게 느껴질 것입니다.