TDD 가이드 라인은 큰 범위로 시작하거나 기초에서 시작한다고 말하고 있습니까?

Question

TDD 지침을 따를 때 작성해야 할 첫 번째 테스트는 무엇입니까? 전체 시스템 또는 가장 작은 핵심 방법에 대한 테스트?

예 : 프로젝트는 CSV를 읽고 XML로 변환해야합니다. 내 첫 번째 테스트는해야한다 :

1. 은 CSV (입력)과 해당 XML (예정) 및 응용 프로그램이 제대로 변환을 수행하는 경우 (Assert.AreEqual (예상, 실제)) 검사를 받아?

2. CSV (입력) 및 해당 메모리 표현 (예상)을 가져 와서 올바르게 구문 분석되는지 (Assert.AreEqual (expected, actual)) 확인하십시오.

두 번째 옵션은 첫 번째 옵션으로 표시되는 전체 목표를 달성하는 데 사용되는 방법 중 하나를 나타냅니다.

Answer 1

먼저 큰 그림 아이디어를 가지고 있어야하지만 아이디어를 얻은 후에는 작게 시작해야합니다. 가장 먼저해야 할 일이 무엇인지 결정하십시오. 예를 들어, 입력 행을 제공하는 메소드를 원한다고 가정하면, 개별 값의 콜렉션을 문자열로 리턴합니다. 첫 번째 테스트에서는 값의 문자열 인 "1,2,3"을 사용하고 문자열 { "1", "2", "3"}을 기대합니다. 서로 다른 값의 수와 유형을 변경하는 테스트를 더 작성합니다. 빈 문자열에 대한 테스트를 추가하십시오. 분명히, 당신은 정확한 기대가 무엇인지 모릅니다. 그래서 위를 가능한 한 방법으로 생각하고 원하는 것을 할 수있는 방법이 아니라고 생각하십시오.

원하는 최종 결과를 염두에두고 기능을 천천히 구축하여 테스트를 통해 응용 프로그램의 전체 디자인을 이끌어 낼 수 있습니다. 나는 당신이 TDD를 성공적으로 시작할 수 있다고 생각하지 않습니다. 왜냐하면 당신이 커다란 시작을한다면, 한 단계에서 아무 것도 할 수없는 완전한 기능으로 도약해야하기 때문입니다. TDD는 궁극적 인 목표를 향해 조금씩 점진적으로 단계를 밟아 가면서 디자인과 코드가 성장하도록합니다.

Answer 2

어느 쪽이든 더 쉽게 발생합니다. 때로는 더 낮은 레벨을 조롱 할 수있을 때 최상위 레벨부터 시작하는 것이 좋습니다. 다른 때에는 낮은 수준에서 시작하여 거기에서 올라가는 것이 좋습니다.

필자는 종종 맨 위 (예 : UI 모델)에서부터 시작합니다. 특히 하위 수준이 무엇인지에 대한 명확한 그림이없는 경우가 많습니다. 그러나 전반적인 아키텍처에 대한 명확한 그림이 있고 시스템이 크면 필요할 것으로 예상되는 하위 구성 요소부터 시작할 수 있습니다.

"프로젝트에서 CSV를 읽고 XML로 변환해야합니다"라는 메시지가 표시되면 비어있는 CSV 파일 (실제로는 메모리 내 문자열)을 비어있는 일부 목록으로 변환하는 것부터 시작합니다. 메모리 내 표현. 한 번에 하나의 전환을 수행하는 것은 책임을 분리하는 이점을 가지며, 전환의 어느 부분에 버그가 있는지 더 잘 알 수 있습니다.

좋은 시작을 얻으려면 충분히 사소한 테스트를 거쳐야합니다. 그런 다음 한 행과 한 열로 CSV 파일을 변환하기위한 테스트를 작성할 수 있습니다. 그것이 어떻게 진행되는지에 따라 - 하향식으로 작업하기가 너무 힘들다면, 좀 더 작은 부품을 상향식으로 만들거나 하위 레벨 구성 요소 중 일부를 조롱하기로 결정할 수 있습니다.