ETL 및보고 프로젝트에 대해 어떻게 단위 테스트를 사용하여 TDD 방법을 사용합니까?


12

ETL 프로젝트는 SSIS, PowerCenter 등과 같은 ETL (추출-변환-로드) 도구를 사용하여 작성된 프로젝트입니다.

일반적으로 외부 소스에서 데이터를 읽고 스테이징 데이터베이스로로드하고 특정 변환을 수행하여 최종 데이터베이스로로드합니다.

간단한 예는 SSIS를 사용하여 SSIS를 사용하여 학교 교사가 제공 한 Excel 파일을 읽고 데이터베이스에로드하는 것입니다. 그런 다음 저장 프로 시저 또는 더 많은 SSIS 패키지를 작성하여 각 학생의 성적을 계산하고 해당 데이터를 데이터 마트 /웨어 하우스에로드하십시오.

그런 다음 마트 위에 스토어드 프로 시저를 빌드하여 시각화를 생성하기 위해보고 도구 (SSRS \ Excel \ etc)에서 사용하는 출력을 생성합니다.

이 시나리오에서 TDD 및 적절한 단위 테스트를 수행하는 방법을 이해하려고합니다. ETL 테스트는 대부분 준비 테이블에로드 된 데이터가 소스 데이터의 올바른 하위 집합인지 확인하는 것입니다. 따라서 테스트를 구현하면 ETL의 미니 버전이 구현됩니다. 보고서 SP의 출력은 테이블 자체의 데이터에 따라 달라 지므로 제거 된 테스트 데이터가 포함 된 데이터베이스를 만들더라도 유지 관리의 악몽없이 안정적인 출력 데이터 세트를 가질 수 없습니다.

예:

스프린트 1 : 학생 테이블 이름, 나이, 학년을 포함

이 테이블에 대한 테스트 데이터를 작성하고이를 기반으로하는 단위 테스트

스프린트 2 : 성별 필드가 테이블에 추가됩니다.

이제 성별 필드를 채우기 위해 학생 필드의 데이터를 새로 고치면 데이터가 변경된 후 테스트 케이스가 무효화됩니다. 그리고 그렇지 않으면 성별 열이 필요한 테스트 사례를 만들 수 없습니다.


테스트하는 도구가 이미 존재하는 경우 TDD가 아닙니다. 일반적인 테스트 만 작성하십시오.
Robert Harvey

@RobertHarvey 실제로 C # 코드를 작성할 때 ETL 도구는 .Net Framework와 다르지 않습니까? 따라서이 도구는 .Net 프레임 워크가 존재하는 것과 같은 방식으로 존재하지만 C #에서 사용자를 수행 할 수 있습니다
user87166

프레임 워크 메서드도 테스트하지 않습니다. 나는 그들이 이미 작동한다고 가정합니다. ETL 도구의 구성을 테스트하는 경우 ETL 도구에서 논리를 다시 작성하지 않아도됩니다. 도구를 사용하십시오.
Robert Harvey

1
그런 다음 ETL, 제안 된 데이터 및 제안 된 구성에서 얻을 것으로 예상되는 기대치를 사용하여 테스트를 작성하십시오. 원하는 경우 개념 테스트를 수행하되 기능은 이미 존재합니다. 순수한 "테스트 우선"개발은 아직 존재하지 않는 것들을위한 것입니다. 무엇을 하든지 ETL 도구를 재발 명하지 마십시오!
Robert Harvey

2
"기본 데이터의 연령이 변경되었으므로" 입력으로 안정적인 테스트 데이터를 제공하는 것이 어려운 이유는 무엇 입니까? 시간에 따른 계산이 필요한 경우 기준 타이머를 조롱하십시오.
Doc Brown

답변:


2

내가 과거에 한 일은 Acceptance Test Driven Development 입니다. ETL 코드는 종종 여러 단계 / 언어 및 기술에 분산되어 있으며 밀접하게 결합되어 있습니다. 대부분의 ETL 프로세스는 파이프 라인의 변환 순서에 따라 다릅니다.

ETL에서만 단위 테스트를 사용할 때의 위험은 통합을 다루지 않는다는 것입니다. 변환 순서는 많은 ETL의 실제 변환과 동일합니다. 자동화 된 테스트 스위트를 만드는 데 리소스를 사용하고 있다면 시퀀싱에도 적용됩니다.

각 고유 한 변환 시퀀스에 대해 TDD에 중점을 두거나 적어도 이러한 테스트를 더 큰 테스트 스위트에 포함시킵니다. 조합이 너무 많으면 테스트 할 시퀀스를 선택하고 선택해야 할 수 있습니다. 아이디어는 사용될 데이터 세트의 ETL 파이프 라인을 유효성 검증하는 것입니다. 뿐만 아니라 모든 코드에서 테스트 범위를 갖도록해야합니다.


0

ETL은 TDD로 수행 할 수 있으며 대부분의 프로젝트와 유사하게 테스트합니다.

실패한 테스트 작성 (빨간색) 실패 수정 (녹색) 코드 성능 및 유지 보수 가능 (리 팩터)

따라서 ETL의 경우 다음과 같습니다.

  • 1 레코드를로드하는 스크립트 작성
  • 실패 (데이터 소스가 정의되지 않음)
  • 소스 정의 [녹색]
  • 리 팩터 필요 없음
  • 1 개의 필드 만 채워져있는 1 개의 레코드를로드하는 테스트 작성
  • 실패 (해당 필드에 작성된 코드가 없음)
  • 해당 필드에 대한 코드 세부 사항 정의
  • 리팩터링
  • 유효한 값을 가진 속성을 찾는 실패한 테스트 정의 [red]
  • 기타

처음 8 단계는 TDD와 아무런 관련이 없습니다. TDD는 테스트를 남기지 않기 때문입니다. 나머지는 명확하지 않습니다.
Bulat
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.