시스템을 통해 내부 멤버에 액세스 하시겠습니까?

StackOverflow https://stackoverflow.com/questions/171332

  •  05-07-2019
  •  | 
  •  

문제

많은 내부 기능을 가진 클래스를 테스트하려고합니다. 이것들은 분명히 테스트가 필요하지만 테스트 프로젝트는 주로 많은 소규모 관련 프로젝트를 다루기 때문에 별도입니다. 지금까지 가지고있는 것은 다음과 같습니다.

FieldInfo[] _fields = 
    typeof(ButtonedForm.TitleButton).GetFields(
        BindingFlags.NonPublic | BindingFlags.Instance | 
        BindingFlags.DeclaredOnly);
Console.WriteLine("{0} fields:", _fields.Length);
foreach (FieldInfo fi in _fields)
{
    Console.WriteLine(fi.Name);
}

이것은 모든 개인 회원을 멋지게 뱉어 내지 만 여전히 내부를 표시하지는 않습니다. Visual Studio가 제작할 수있는자가 생성 테스트를 망칠 때 테스트 프로젝트에 내부를 표시하는 것과 관련이 있기 때문에 이것이 가능하다는 것을 알고 있습니다. 글쎄, 이제 나는 nunit을 사용하고 정말 좋아하지만 어떻게 같은 것을 달성 할 수 있습니까?

도움이 되었습니까?

해결책

사용하는 것이 더 적절합니다 InternalsVisibleTo 어셈블리의 내부 멤버에 대한 액세스 권한을 부여하여 단위 테스트 어셈블리에 속합니다.

다음은 유용한 추가 정보와 통과하는 링크입니다.

실제로 귀하의 질문에 답하기 위해 ... 내부 및 보호는 .NET Reflection API에서 인식되지 않습니다. 다음은 인용문입니다 MSDN:

C# 키워드 보호 및 내부는 IL에서 의미가 없으며 반사 API에는 사용되지 않습니다. IL의 해당 용어는 가족 및 조립입니다. 반사를 사용하여 내부 방법을 식별하려면 ISASSEMBLY 재산. 보호 된 내부 방법을 식별하려면 ISFAMILYORASSEMBLY.

다른 팁

추가 InternalSvisibleto 메인 프로젝트에 대한 조립 레벨 속성, Thre Test 프로젝트의 어셈블리 이름으로 내부 구성원이 보이도록해야합니다.

예를 들어 모든 수업 이외의 어셈블리에 다음을 추가하십시오.

[assembly: InternalsVisibleTo("AssemblyB")]

또는보다 구체적인 타겟팅 :

[assembly:InternalsVisibleTo("AssemblyB, PublicKey=32ab4ba45e0a69a1")]

응용 프로그램 어셈블리의 이름이 강한 경우 테스트 어셈블리도 강력하게 이름을 지정해야합니다.

개인 방법에 대한 단위 테스트를 작성 해야하는지 물어봐야한다고 생각하십니까? '합리적인'코드 범위를 사용하여 공개 방법에 대한 단위 테스트를 작성하는 경우 결과적으로 호출 해야하는 개인 방법을 이미 테스트하지 않습니까?

테스트를 개인 방법으로 묶으면 테스트가 더욱 부서지기 쉬워집니다. 테스트를 중단하지 않고 개인 방법의 구현을 변경할 수 있어야합니다.

참조 :

http://weblogs.asp.net/tgraham/archive/2003/12/31/46984.aspx http://richardsbraindump.blogspot.com/2008/08/should-i-unit-test-private-methods.html http://junit.sourceforge.net/doc/faq/faq.htm#tests_11 http://geekswithblogs.net/geekusconlivus/archive/2006/07/13/85088.aspx

귀하의 코드는 필드 만 표시하고 있으므로 필드는 항상 개인 IMO 여야하므로 내부 멤버가 표시되지 않기를 바랍니다. (상수의 잠재적 인 제외.)

ButtonEdform.titleButton은 실제로 비 개인 분야가 있습니까? 내부를 찾으려고한다면 행동 양식 그런 다음 분명히 당신은 전화해야합니다 GetMethods (또는 GetMembers) 그들에게 도착합니다.

다른 사람들이 제안한 것처럼 InternalsVisibleTo 테스트에 매우 편리합니다 (거의 테스트에만 적합합니다!). 내부 방법을 테스트 해야하는지 여부는 분명히 그렇게 할 수있는 것이 유용하다고 생각합니다. 나는 단위 테스트를 존재로 간주하지 않습니다 독점적으로 블랙 박스 테스트. 간단한 방식으로 연결된 몇 가지 내부 방법을 사용하여 공개 기능이 구현된다는 것을 알면 종종 각 내부 방법과 공개 방법에 대한 일부 "의사 통합"테스트를 철저히 테스트하는 것이 더 쉽습니다.

내부를 사용하는 것에 대한 정당성은 내 상황에 처해 있습니다. 우리는 차트 컨트롤에 소스 코드를 구매합니다. 우리는 해당 소스 컨트롤을 수정하고 자체 버전을 컴파일 해야하는 곳을 찾았습니다. 이제 우리가 아무 것도 깨지지 않도록하기 위해 일부 내부 필드에 대한 액세스가 필요한 단위 테스트가 있습니다.

이것은 내부 파악할 수있는 완벽한 경우입니다.

그래도 소스에 액세스 할 수 없다면 어떻게해야합니까? 내부 필드에 어떻게 갈 수 있습니까? .NET Reflector는 해당 코드를 볼 수 있지만 IL을보고있는 것 같습니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top