단위 테스트를위한 데이터베이스 종속성 피하기

Question

데이터베이스 액세스가 필요한 메소드를 가진 많은 객체가 있습니다. 우리는 단위 테스트를 원하지만 가능한 경우 모의 객체 사용을 피하려고합니다. 아래에 표시된 Validate 메서드를 리팩터링하여 DB 액세스가 필요하지 않은지 궁금합니다. 실제 응용 프로그램에서는 일반적으로 더 많은 일이 발생하지만이 단순화 된 예제만으로 충분하다고 생각합니다.

모의 객체를 사용하는 법을 배울 것입니다. 그러나 오버 헤드가 많은 것처럼 보입니다. 그래서 대안을 찾고 있습니다.

public class Person 
    { 
     public string Name; 

     public string Validate() 
     { 
      if (PersonDA.NameExists(Name)) 
      { 
       return "Name Already Used"; 
      } 

     } 
    } 

Answer 1

개인적으로 나는 모의 객체 경로로 이동합니다. 훨씬 더 유연하며 실제 객체에 테스트 코드를 넣는 경로를 원한다고들할까요?

물론, 검증 코드를 부울 isValid (Person) 메소드를 사용하여 PersonValidator 객체로 추출하십시오. 그런 다음 테스트 코드에서 테스트 케이스에 따라 true 또는 false를 반환하는 mock 유효성 검사기를 사용합니다.

Answer 2

단위 테스트에 사용되는 데이터베이스를 설정해야합니다. 모든 데이터 액세스에 실물 모형을 사용한다면 실제로 테스트를 많이하지 않겠습니까? :)

Answer 3

특히 작은 테스트 데이터베이스를 채우도록 설정되어 있으므로 유닛 테스트 중에 모의 데이터베이스에서 실제 개체를 사용할 수 있습니다. 그것으로 테스트하는 것은 모의 객체를 개발하는 것보다 훨씬 쉬우 며 데이터 액세스 코드를 수정하는 것보다 훨씬 안전하고 훨씬 더 철저합니다.

Answer 4

Person 클래스는 데이터베이스 액세스 코드에 숨겨진 정적 종속성이 있으므로 단위 테스트가 어렵습니다. Person과 상태를 검증하는 데 필요한 정보를 제공하는 새로운 유형의 오브젝트간에 동적 공동 작업을 도입하여 이러한 결합을 깨뜨릴 수 있습니다. Person의 유닛 테스트에서, Person 오브젝트의 "stub"구현을 협력자에게 전달하여 데이터베이스에 타격하지 않고 유효하거나 무효 한 경우에 일어날 일을 테스트 할 수 있습니다.

별도의 테스트 세트에서 데이터베이스에 맞는 실제 구현을 테스트 할 수 있습니다. 이러한 테스트는 느리지 만 접근 자 메서드를 복잡한 논리없이 데이터베이스 쿼리로 직접 변환하기 때문에 테스트 횟수가 줄어들 것입니다.

원한다면 "모의 객체 사용"이라고 부를 수 있습니다. 그러나 현재 디자인은 명령을 기대하지 않고 쿼리를 스텁해야한다는 것을 의미하기 때문에 모의 객체 프레임 워크는 너무 복잡한 도구입니다. 직접 작성한 스텁은 테스트 실패를 쉽게 진단 할 수있게합니다.

Answer 5

왜 모의 동물을 정확히 피하려고합니까? 단위 테스트를 연습하고 데이터 액세스 코드가 있다면 모의/스텁/주입 방식에 익숙해지기가 가장 쉽습니다.

조롱 프레임 워크를 가져 오지 않기 때문에 필요한 경우 간단한 스텁을 코딩 할 수 있습니다.

데이터 액세스 코드를 인터페이스 뒤에두면 데이터베이스가 필요하지 않게됩니다. 테스트 중에 모의 (mock) 또는 스텁 (stub) 데이터 액세스 코드를 삽입하려면 종속성 삽입을 사용하는 것이 좋습니다.