2011-02-25 4 views
1

처음에 질문이 이미 제기되었지만 광산과 같은 사람을 찾지 못해서 미안합니다 (하지만 꽤 일반적인 질문이라고 생각합니다). 그래서 나는 단위 테스트를하려고합니다. 첫 번째 문제는 이미 문제가 있습니다.비공개 필드에 액세스하기

생성자에서 개인 필드의 인스턴스를 설정했습니다.이 개인 필드가 null이 아닌지 어떻게 테스트합니까? (내가 무엇을 테스트하는 것으로 가정하기 때문에) -> 테스트하려면 :

public BUDGET_MANAGER() 
    { 
     this.budget_provider = new BUDGET_PROVIDER(); 
    } 

-> 테스트 Mehod :

[TestMethod()] 
    public void BUDGET_MANAGERConstructorTest1() 
    { 
     BUDGET_MANAGER target = new BUDGET_MANAGER();  
     Assert.IsNotNull(??,"the provider is not instancied"); 

    } 

내가 어떻게 할 수 있습니까? 도움을 주셔서 감사합니다, 나는 단위 테스트에서 꽤 길을 잃었습니다.

+1

참조 : http://msdn.microsoft.com/en-us/library /0tke9fxk.aspx ('private'대신에'internal' 필드를 만들어야합니다.) –

+0

[Unit 변수를 테스트하고 사적인 변수 값을 확인할 수 있습니다] /stackoverflow.com/questions/1093020/unit-testing-and-checking-private-variable-value) –

답변

4

유닛 테스트에서는 클래스에 비공식적 인 테스트를하지 않아도됩니다. 개인적으로 내부적으로 만 알려진 멤버는 클래스 구현의 일부이며 노출 된 (테스트 된) 기능의 일부가 아닙니다.

기본적으로 클래스의 외부에서 볼 수있는 멤버를 "계약"이라고 생각하십시오. 그것은 실제 유형을 정의하고, 그 밖의 모든 것을 봅니다. 이것이 테스트중인 기능입니다. 내부 (개인) 멤버는 매우 좋은 이유로 클래스 외부에서 알지 못합니다. 다른 클래스는 다른 개인 멤버와 다른 방식으로 동일한 "계약"(또는 인터페이스)을 구현할 수 있습니다.

보이는 기능, 계약 또는 인터페이스입니다.

+0

제 경우에는 검사 할 것이 없습니다. – bAN

+0

@bAN : 수업에 따라 다릅니다. "유형"(인터페이스, 묵시적 또는 명시 적)이 "클래스"(구현)와 밀접하게 결합 된 경우 단위 테스트는 일부 재검토 및 가능한 리 팩토링이 순서대로 이루어질 수 있음을 나타냅니다. 인터페이스의 개념을 클래스와 분리하면 테스트가보다 명확 해집니다. (덧붙여 말하자면, 이것은 긍정적 인 테스트 결과입니다. 변경해야 할 클래스에 대한 정보를 결정합니다.) 그렇지만 대답하려면 예, 개인 회원과 관련하여 테스트 할 사항이 없습니다. 공용 기능 만. – David

2

단위 테스트는 이 아니고 개인 데이터를 검사해야합니다. 개발자는 구현 세부 사항과 관계없이 클래스의 인터페이스에 정의 된 동작이 작동하는지 테스트해야합니다.

일반적인 테스트는 생성자를 호출 한 다음 나중에 공용 속성이나 메서드를 호출하고 결과가 예상 한 것과 같은지 확인합니다. 이 방법으로 테스트하면 나중에 구현을 변경하여 (예를 들어) 필요할 때만 BudgetProvider를 지연 생성하면 모든 테스트가 여전히 작동합니다. 비공개 멤버가 null인지 여부와 같은 구현 세부 정보는 클래스의 클라이언트와 관련이 없으므로 단위 테스트에서 테스트 할 필요가 없습니다.

+0

단위 테스트가 개인 정보를 검사하지 않아야한다고 생각합니까? 그렇다면 합의했다. – Paul

+0

@Paul : 네, 고마워요! 그것이 실제로 내가 쓰려고 의도 한 것입니다. –

1

mstest를 사용하는 경우 원래 클래스를 마우스 오른쪽 단추로 클릭하고 Create Test Accessor를 눌러 테스트 프로젝트를 선택하십시오. 그런 다음 접근자를 사용하여이 조건을 테스트합니다 (intellisense에 표시되어야 함).

다른 포스터에서 말한 것처럼 나는 그 생각을 잘 모르겠다. 구현을 변경하기가 더 어려워 질 것입니다.

1

클래스의 개인 변수를 실제로 테스트하면 안됩니다.

왜 생성자 자체를 테스트 하시겠습니까? 일부 로직이 있으면 테스트하는 것이 좋습니다. 예를 들어, 주어진 매개 변수가 정확하고 객체를 만들기 전에 유효성 검사를 수행하는 경우에만 객체를 생성합니다. 그렇지 않으면 개체를 생성하고 예상대로 작동하는지 확인하십시오. 아마도 생성자가 올바르게 작동하지 않으면 객체의 동작도 올바르지 않을 것입니다.

또한 생성자에서 올바르게 설정되었는지 확인하기 위해 개인 필드를 속성으로 표시하려는 유혹에 저항하십시오.

+0

감사합니다. 그리고이 생성자의 private budget_provider에 값 (생성자 매개 변수)을 설정하는 경우 budget_provider를 조롱하여 budget_provider에서 집합이 호출되는지 테스트합니다. – bAN

+0

예. 그것은 매우 좋은 접근 방법입니다 - 클래스의 상호 작용과 그 의존성을 테스트합니다 (budget_provider). 예상되는 상호 작용이 객체의 상태에 따라 발생하는지 확인할 수 있습니다. – mfloryan

0

다른 사람들은 단위 테스트를 할 때 수행하지 말아야 할 것을 언급했습니다.

난 당신이 (당신은 여전히 ​​당신의 생성자를 테스트 할 필요가) 원하는 것을 할 수있는 방법을 찾기 위해 노력하겠습니다 :

public BUDGET_MANAGER() 
{ 
    try 
    { 
     this.budget_provider = new BUDGET_PROVIDER(); 
    } 
    catch {} 

    if (this.budget_provider == null) 
     throw new NullReferenceException("Budget provider is null !"); 
} 
+0

불쾌감은 없지만 이것은 우습다. CLR이 손상되지 않으면 "new"는 null을 반환 할 수 없습니다. 사례 :이 예외가 발생했음을 보여주는 테스트를 작성하십시오. – bryanbcook

+0

기본적으로 코드 블록을 '의사 코드'로 간주해야합니다. 아시다시피, 원래의 질문도 똑같은 문제가 있습니다. 그러나 우리는 그가 가독성에 대한 브리핑을했다고 가정합니다. 나는'new' 키워드에'try/catch'를 추가하여 행복하게 만들었습니다. – Xaqron