내가 이해하는 한, 대부분의 사람들은 개인 메소드를 직접 테스트하지 말고 공개 메소드가 호출하는 방식을 통해 테스트해야한다는 데 동의하는 것 같습니다. 나는 그들의 요점을 볼 수 있지만 "TDD의 3 가지 법칙"을 따르고 "적색-녹색-리 팩터"주기를 사용할 때 이것에 약간의 문제가 있습니다. 예를 들어 설명하는 것이 가장 좋습니다.
지금은 탭으로 구분 된 데이터가 포함 된 파일을 읽고 숫자가 아닌 데이터가 포함 된 모든 열을 필터링 할 수있는 프로그램이 필요합니다. 아마 이미이 작업을 수행 할 수있는 몇 가지 간단한 도구가있을 것 같지만 TDD로 연습 할 수있는 멋지고 깨끗한 프로젝트가 될 수 있다고 생각했기 때문에 처음부터 직접 구현하기로 결정했습니다.
따라서 먼저 "빨간 모자를 착용하십시오", 즉 실패한 테스트가 필요합니다. 숫자가 아닌 모든 필드를 한 줄에서 찾는 방법이 필요하다고 생각했습니다. 그래서 간단한 테스트를 작성합니다. 물론 즉시 컴파일되지 않으므로 함수 자체를 작성하기 시작하고 몇 번의주기 (빨간색 / 녹색)가 끝나면 작동하는 함수와 완전한 테스트가 있습니다.
다음으로 한 번에 한 줄씩 파일을 읽고 각 행에서 "findNonNumericFields"함수를 호출하여 결국 제거해야하는 모든 열을 수집하는 "gatherNonNumericColumns"함수를 계속 사용합니다. 적록주기가 몇 번되었고 작동 기능과 완전한 테스트를 다시 마쳤습니다.
이제 리팩토링해야한다고 생각합니다. "findNonNumericFields"메소드는 "gatherNonNumericColumns"를 구현할 때 필요하다고 생각했기 때문에 설계되었으므로 "findNonNumericFields"를 비공개로 설정하는 것이 합리적이라고 생각됩니다. 그러나 더 이상 테스트하는 방법에 액세스 할 수 없으므로 첫 번째 테스트가 중단됩니다.
그래서 나는 개인적인 방법과 그것을 테스트하는 일련의 테스트로 끝납니다. 많은 사람들이 개인적인 방법을 테스트해서는 안된다고 조언하기 때문에 여기 모퉁이에 그려진 것처럼 느껴집니다. 하지만 정확히 어디서 실패 했습니까?
나는 더 높은 수준에서 시작할 수 있었으며 결국 내 공개 메소드가 될 것 (즉, findAndFilterOutAllNonNumericalColumns)을 테스트하는 테스트를 작성했지만 TDD의 전체 지점에 다소 반대되는 느낌을 얻었습니다 (최소한 밥 삼촌에 따르면) : 테스트 작성과 프로덕션 코드 간을 끊임없이 전환해야하며 어느 시점에서든 모든 테스트가 마지막 1 분 안에 작동했습니다. 공개 메소드에 대한 테스트를 작성하여 시작하면 개인 메소드의 모든 세부 정보가 작동하여 테스트를 공개하기 전에 몇 분 (또는 매우 복잡한 경우에는 며칠 또는 몇 일)이 걸릴 수 있기 때문에 메소드가 전달됩니다.
그래서 뭐 할까? TDD (빨간색-녹색-리 팩터 사이클이있는)는 단순히 개인용 메소드와 호환되지 않습니까? 아니면 내 디자인에 결함이 있습니까?
private그렇게하는 것이 타당한 것처럼 숨 깁니다 .