큰 응용 프로그램의 테스트 데이터 관리

비교적 큰 웹 API 응용 프로그램이 있습니다. 즉, 현재 ~ 300 개의 테이블이 있습니다.큰 응용 프로그램의 테스트 데이터 관리

앱은 저장 프로 시저를 사용하지 않고보기가없는 방식으로 작성됩니다. 즉, 비즈니스 로직이 모두 앱 코드에 있습니다. 저장소 패턴을 사용하므로 단위 테스트를위한 모의 데이터를 만드는 것이 상대적으로 쉽습니다.

그러나 모의 데이터를 관리하는 것은 매우 어렵고 특정 개인이 이미 존재하는 데이터에 대한 통찰력을 얻기가 매우 어렵습니다. 우리는 테스트 데이터를 모의 팩토리로 이동하여 단일 파일에 저장하여 다양한 테스트가 필요에 따라로드되도록했습니다 (예 : 주어진 테스트는 데이터의 특정 하위 집합 만 필요하므로 단지 해당 하위 집합에 대해 물어보십시오).

여전히 데이터 관리는 매우 복잡하며 응용 프로그램에서 반환 된 데이터가 취약하다는 주장도 있습니다. 예를 들어 모의 데이터에 10 명의 고객이 정의되어 있고 그 중 2 명이 비활성으로 표시됩니다. 모든 활성 고객을 반환해야하는 메소드가 8 개의 인스턴스를 반환해야 함을 테스트하는 테스트 사례가있을 수 있습니다. 그러나 개발자가 테스트 데이터에 새 인스턴스를 추가해야하는 경우 기존 테스트/주장이 중단됩니다.

누구든지이 문제를 관리해 본 경험이 있습니까?

출처

2014-05-17 dabs

각 테스트에 특정 모의 테스트를 사용합니다. 즉 데이터를 공유하지 않습니다. 또한 구체적인 (익명으로 처리 된) 코드 샘플은 더 많은 도움이 될 것입니다. – MikeSW

여러 테스트에 사용되는 테스트 데이터를 만드는 것처럼 들립니다. 이것은 최선의 해결책이 아닙니다. 필요한 데이터를 테스트별로 작성해야합니다. 테스트 데이터 작성기 패턴이 도움이 될 것입니다. 이 link은 테스트 데이터 작성기를 사용하는 방법을 설명합니다. 또한 Mark Seemann은 autofixture이라는 모의 데이터를 작성하는 데 도움이되는 라이브러리를 작성했습니다.

그는 PluralSight에서 멋진 비디오를 advanced unit testing에 있습니다. PluralSight에 액세스 할 수 있다면 비디오를 시청하는 것이 좋습니다.

출처

2014-05-19 05:53:04 Andrew

네, 맞습니다. 그리고 나는 이것이 단점을 가지고 있다는 것에 동의합니다. 각 테스트에 대한 테스트 데이터를 작성하는 것은 자체적 인 단점을 가지고 있습니다. 즉, 중복 데이터가 발생할 수 있습니다. 거기에 중간 도로가있는 것 같아요, 그냥 찾아야합니다. – dabs

나는 내가 따라 왔는지 확신하지 못한다. 위의 예를 들고 테스트 데이터 빌더를 적용하면 빌더는 다음과 같이 보일 것입니다. var cust1 = CreateCustomerBuilder(). WithInactiveSetTo (true) .Build(); var cust2 CreateCustomerBuilder(). WithInactiveSetTo (false) .Build(); 비활성 고객이 생성되었는지 테스트하기 위해 행을 더 이상 필요하지 않습니다. 또한 고객의 다른 속성에 대한 값을 알 필요도 없습니다. 테스트 데이터 빌더는 임의의 값을 할당 할 수 있습니다. – Andrew

큰 응용 프로그램의 테스트 데이터 관리

답변

관련 문제