테스트 데이터를 어디에 저장해야합니까?


9

실제 데이터 세트의 작은 스 니펫을 사용하는 더 작은 단위 테스트가 있습니다. 또한 여러 가지 이유로 전체 데이터 세트에 대해 프로그램을 테스트하고 싶습니다. 유일한 문제는 하나의 실제 데이터 세트가 약 5GB라는 것입니다. Git 리포지토리에 저장할 수있는 하드 번호를 찾지 못했지만 너무 많이 보입니다.

이 프로그래머 포스트에 따르면 프로젝트를 테스트하는 데 필요한 모든 데이터를 저장소에 보관해야합니다.

우리 팀이 채택한 솔루션은 프로젝트에 테스트 데이터를 보유한 네트워크 연결 파일 시스템에 대한 경로가 포함 된 파일이 있다는 것입니다. 파일은 힘내 무시됩니다.

나는 이것이 두 가지 이유로 불완전한 해결책이라고 생각합니다. NAS가 작동하지 않거나 속도가 느리거나 다운되면 전체 테스트를 실행할 수없는 것입니다. 두 번째 이유는 누군가 저장소를 처음 복제 할 때 단위 테스트가 실패하기 때문에 특정 이름으로 테스트하는 방법과 테스트 경로 파일을 작성하는 데 사용되는 구문을 파악해야하기 때문입니다.

제 질문은 두 가지입니다. 개정 관리에 저장하기에 너무 많은 데이터가 얼마나 많은 데이터입니까?

대량의 테스트 데이터를 처리하는 더 좋은 방법은 무엇입니까?


1
테스트 데이터는 얼마나 자주 변경됩니까?
Robert Harvey

아마도 변경되지는 않지만 버그를 패치하거나 기능을 추가함에 따라 더 많은 데이터가 추가 될 수 있습니다.
AlexLordThorsen

1
일부 절충점은 여기에서 살펴볼 수 있습니다 : stackoverflow.com/q/984707
Robert Harvey

1
git의 내용에 관계없이 라이브 데이터의 전체 데이터 세트가 테스트 데이터 세트가 아니며 (성공 및 실패 상태를 모두 테스트하도록 설계됨) 홀드해야 할 강력한 논거가 될 수 있다는 관점에서 고려 했습니까? 저장소 외부?
James Snell

단위 테스트는 많은 양의 데이터를 사용하지 않아야합니다. 통합 테스트가 가능할 수도 있습니다.
raptortech97

답변:


9

빌드 체인에서 큰 파일을 처리하는 방법

maven 또는 gradle과 같은 종속성 관리를 수행하는 빌드 도구를 사용하고 싶습니다. 파일은 웹 저장소에 저장되며 도구는 종속성이 발생하면 자동으로 다운로드 및 캐싱을 처리합니다. 또한 테스트를 실행하려는 사람들을위한 추가 설정 (NAS 구성)을 제거합니다. 또한 데이터를 새로 고치는 데 어려움이 없습니다 (버전이 지정됨).

개정 관리에 넣기가 너무 큰 것

큰 회색 영역이 있습니다. 그리고 어떤 것이 RCS에 속하지 않는다고 결정하면 대안은 무엇입니까? RCS와 이진 저장소 (maven 스타일) 사이의 선택을 제한하면 더 쉬운 결정입니다.

이상적으로는 인간적으로 편집 가능하거나 확산 가능하거나 기록을 추적하려는 RCS 항목 만 원할 것입니다. 빌드 또는 다른 종류의 자동화의 산물은 분명히 거기에 속하지 않습니다. 크기는 제한적이지만 주된 것은 아닙니다. 거대한 소스 파일 (나쁜 습관)은 소스 컨트롤에 속합니다. 작은 컴파일 된 바이너리는 그렇지 않습니다.

개발자 편의를 위해 타협 할 준비를하십시오.


3

NAS가 작동하지 않거나 속도가 느리거나 다운되면 전체 테스트를 실행할 수없는 것입니다.

분명히 이것은 5GB를 NAS에서 로컬 드라이브로 복사해야만 해결할 수 있습니다. 그러나이 작업을 수동으로 수행 할 필요는 없습니다.

두 번째 이유는 누군가 저장소를 처음 복제 할 때 단위 테스트가 실패하기 때문에 특정 이름으로 테스트하는 방법과 테스트 경로 파일을 작성하는 데 사용되는 구문을 파악해야하기 때문입니다.

정확한 이름을 가진 간단한 셸 스크립트를 제공 할 수 있습니다. NAS에 특정 이름으로 마운트하고 로컬 드라이브가 없거나 로컬에있는 데이터 세트가 로컬 데이터 세트보다 최신 인 경우 로컬 드라이브에 데이터를 복사합니다. 단위 테스트의 초기화 단계에서 스크립트가 자동으로 실행되는지 확인하십시오.

물론 이러한 데이터 세트 중 하나만이 아니라 소스 코드 저장소 외부의 외부 파일에 대한 전체 종속성이있는 경우 @ptyx에서 언급 한 것과 같은 도구가 더 나은 솔루션 일 수 있습니다.


3

... 누군가가 먼저 저장소를 복제 할 때 단위 테스트가 실패하므로 테스트 경로 파일을 빌드하는 데 사용되는 구문과 특정 이름으로 마운트하는 방법을 알아 내야합니다.

첫째, 일관된 용어를 사용하는 것입니다. 이러한 종류의 테스트 (대형 외부 종속성, 실제 데이터)는 일반적으로 단위 테스트가 아니라 통합 또는 시스템 테스트로 간주됩니다 .

실용적인 참고 사항 : 단위 및 통합 테스트 는 서로 다른 강도와 약점이 있기 때문에 분리 하여 유지하는 것이 좋습니다 .

  • 코드에서 두 종류의 테스트를 분리하십시오 (이름 지정 규칙, 별도의 프로젝트 등).
  • 두 가지 테스트 스위트 중 하나만 실행할 수있는 방법을 제공합니다.
  • 일반 빌드 중에 단위 테스트 만 실행
  • 주문형 및 CI (연속 통합) 서버에서 통합 테스트 실행

이렇게하면 로컬 빌드가 빠르고 안정적이며 (외부 종속성이 거의 없음) 통합 CI는 강력한 CI 서버에서 처리합니다. 이것은 당신이 설명하는 문제를 피합니다.

데이터를 유지하는 방법에 대해 :

한 가지 좋은 옵션은 ptyx의 답변과 같은 일종의 아티팩트 관리입니다. 다른 하나는 테스트 데이터를 별도의 저장소 에 넣는 것 입니다. 데이터는 기본 빌드와 함께 릴리스되지 않으며 별도의 저장소를 사용하면 모든 사람이 소스 코드와 함께 테스트 데이터를 가져 오지 않아도됩니다. 즉, artifacdt 관리로 두 번째 저장소를 사용하십시오 :-).

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.