일괄 처리를위한 TDD : 어떻게합니까?

RoR 등의 "빨간색 / 녹색 / 리 팩터"등이 좋습니다.

내 일에는 파이썬 및 기타 사용자 정의 도구에서 타사의 대용량 파일을 일괄 처리하는 작업이 포함됩니다.

이러한 파일의 속성에 대한 이탈은 높으므로 많은 수정 / 향상이 자주 적용됩니다.

알려진 결과를 가진 알려진 테스트 데이터 본문을 통한 회귀 테스트가 없습니다. 새로운 테스트 사례를 직접 코딩하여 마지막 배치에 대해 가장 가까운 것이 실행되고 있는지 확인한 다음 스팟 확인 및 통계 테스트를 적용하여 데이터가 여전히 정상인지 확인하십시오.

Q >> 이런 종류의 환경에 TDD 원칙을 도입하는 방법은 무엇입니까?

참고로, 단위 테스트는 TDD와 동일하지 않습니다. TDD는 단위 테스트가 요소 인 프로세스입니다.

그러나 단위 테스트를 구현하려는 경우 다음과 같은 여러 가지 작업을 수행 할 수 있습니다.

모든 새로운 코드 / 강화 테스트

이 방법을 사용하면 이미 존재하는 모든 것을 단위 테스트 할 필요가 없으므로 단위 테스트 구현의 초기 혹이 훨씬 작습니다.

개별 데이터 조각 테스트

많은 양의 데이터를 포함 할 수있는 무언가를 테스트하면 많은 경우와 테스트 범위에 차이가 생길 수 있습니다. 대신 0, 1, many 옵션을 고려하십시오. 0 개 요소, 1 개 요소 및 많은 요소로 '배치'를 테스트하십시오. 요소가 1 개인 경우 해당 요소에 대한 데이터가있을 수있는 다양한 순열을 테스트하십시오.

거기에서 가장자리 사례를 테스트합니다 (상한은 개별 요소의 크기 및 배치의 요소 수에 해당). 테스트를 정기적으로 실행하고 장기간 실행되는 테스트 (대량 배치?)가있는 경우 대부분의 테스트 러너는 분류를 허용하므로 테스트 케이스를 개별적으로 (야간?) 실행할 수 있습니다.

그것은 당신에게 강력한 기반을 제공해야합니다.

실제 데이터 사용

지금처럼 이전에 사용한 '실제'데이터를 제공하는 것은 나쁜 생각이 아닙니다. 특정 형식의 오류를 즉시 알 수 있도록 올바른 형식의 테스트 데이터로이를 보완하십시오. 실제 데이터를 처리하지 못하면 배치 프로세스 결과를 검사하고 오류를 복제하기위한 단위 테스트를 생성 한 다음 유용한 회귀 사례를 통해 빨강 / 녹색 / 리 팩터로 돌아갈 수 있습니다.

다른 환경과 동일합니다.

논리를 가장 작은 단위로 세분화하십시오. 이는 프로세스에 대한 규칙 세트를 제공하며 각 규칙은 프로세스에 필요한 하나의 논리 항목을 포함합니다.

그런 다음 각 규칙에 대한 테스트를 작성하십시오. 이 테스트는 실패합니다. 테스트를 수정하기위한 코드를 작성하십시오.

알고있는 알려진 테스트 데이터를 사용한 회귀 테스트는 단위 테스트가 아닙니다. 그것은 통합 테스트 일 것입니다. 이것은 TDD와 다릅니다. TDD를 사용하면 파일을로드 할 수 있는지 테스트하기위한 단일 테스트가있을 수 있지만 일반적으로 테스트 데이터가있는 데이터 파일 근처에는 다른 테스트가 거의 없습니다. 대신 모의 객체를 사용하여 특정 규칙을 실행하는 데 필요한 데이터를 시뮬레이션합니다.

좋은 소프트웨어 전략으로 시작한 다음 TDD를 적용하십시오.

(면책 조항 : "이탈"또는 TDD 또는 둘 다를 잘못 이해했을 수 있습니다.)

다음은 일괄 처리 "더티 데이터"에 대한 제안 된 전략입니다. Specify-Triage-Execute.

• 엄격하고 좁은 방식으로 데이터 사양을 작성하지만 들어오는 데이터의 대부분 (80 % 이상)을 포함합니다. 이 사양을 호출하십시오 1 .
• 레코드가 사양 1을 충족하는지 결정 하는 심사 모듈 (원하는 경우 TDD)을 개발하십시오 .
  • 모듈이 매우 빠르게 작동하는지 확인하십시오.
  • 모듈은 true / false를 반환해야합니다. 모든 규칙을 충족하거나 충족하지 않습니다.
• 고객이 필요로하는 작업을 수행하여 사양 1을 충족하는 것으로 알려진 레코드를 구문 분석 하는 실행 모듈 (원하는 경우 TDD)을 개발 하십시오.
• 들어오는 모든 데이터에 심사 1 을 적용 합니다.
  • 결과는 각 레코드마다 하나의 부울 값입니다. 기본적으로 들어오는 데이터는 사양 1 또는 알 수 없음으로 구분됩니다.
  • 고객이 필요할 때마다 사양 1 데이터에서 실행 1 을 적용하십시오 .
• 나머지 데이터의 80 %를 허용하려면 사양 1의 규칙을 완화하십시오. 이 사양을 호출하십시오 2 .
• 심사 2 개발 및 실행 2 . 사양 1을 충족하지 않는 모든 데이터에 적용하십시오.
• 나머지 데이터가 매일 수동으로 처리 될 수있을 정도로 작을 때까지 필요한만큼 많은 레벨을 반복하십시오.

효율성 tidbit :

레코드와 관련된 모든 심사 결과 (기록 또는 현재)를 저장하십시오. 마지막 실행 이후 심사 모듈을 수정하지 않은 경우 이전 데이터에서 다시 실행하지 않아도됩니다.

"TDD를하기 전에 무엇을 만들고 싶은지 알아야한다"tidbit :

Specify-Triage-Execute는 각 수준에서 요구 사항을 관리 가능하게 유지하고 향후 성장을 허용하는 한 가지 방법입니다.

(이 세 단계에 대한 올바른 표준 용어를 아는 사람이 있으면 답변을 편집하겠습니다.)