2010-06-14 2 views
6

.NET 어셈블리가 출시되었습니다. 그것의 릴리스 빌드는 다음과 같습니다.NET 어셈블리를 테스트하는 데 사용되는 공용 메서드 숨기기

  • 명 공개, 문서화 된 사람들은 어셈블리를 테스트 할 수 있도록하기 위해 존재하는 다른 방법의
  • 공개하지만 문서화되지 않은 API를 사용하는 가정되는 방법 API 및 사용할 수 없습니다.

출시 될 어셈블리는 응용 프로그램이 아닌 사용자 지정 컨트롤입니다. 회귀 테스트를 수행하기 위해 테스트 프레임 워크/응용 프로그램에서 실행합니다.이 응용 프로그램은 공개/문서화 된 API 이외에도 일부 고급/문서화되지 않은 메서드를 컨트롤에서 내 보냅니다. 이 같은 예를 들어 나는 사람들이 내가합니다 (샌드캐슬 도움말 파일 빌더에서 지원)을 <exclude> 태그를 사용하여 문서에서 그들을 제외, 사용하지 않는 공공 방법 및 [EditorBrowsable] 속성에 대한

:

/// <summary> 
/// Gets a <see cref="IEditorTransaction"/> instance, which helps 
/// to combine several DOM edits into a single transaction, which 
/// can be undone and redone as if they were a single, atomic operation. 
/// </summary> 
/// <returns>A <see cref="IEditorTransaction"/> instance.</returns> 
IEditorTransaction createEditorTransaction(); 

/// <exclude/> 
[EditorBrowsable(EditorBrowsableState.Never)] 
void debugDumpBlocks(TextWriter output); 

이렇게하면 API 설명서와 Intellisense에서 성공적으로 제거됩니다. 나는 메타 데이터의 정의를 볼 수있는 인터페이스의 인스턴스를 마우스 오른쪽 버튼으로 클릭 샘플 응용 프로그램의 경우, 나는 아직도 방법을 볼 수 있으며, [EditorBrowsable] 예를 들어,뿐만 아니라 속성 :

// Summary: 
//  Gets a ModelText.ModelDom.Nodes.IEditorTransaction instance, which helps 
//  to combine several DOM edits into a single transaction, which can be undone 
//  and redone as if they were a single, atomic operation. 
// 
// Returns: 
//  A ModelText.ModelDom.Nodes.IEditorTransaction instance. 
IEditorTransaction createEditorTransaction(); 
// 
[EditorBrowsable(EditorBrowsableState.Never)] 
void debugDumpBlocks(TextWriter output); 

질문 :

  • 공공 방법을 숨길 수있는 방법도 메타 데이터에서 있나요?
  • 대신이 시나리오의 경우 internal 메서드를 만들고 InternalsVisibleTo 특성을 사용 하시겠습니까? 아니면 다른 방법으로 추천 해 주시겠습니까? 그렇다면 무엇을, 왜?

감사합니다.

+5

내가 숨기고 싶은 코드를 공개적으로 노출 할 필요가없는 적절한 디자인을 권장합니다. –

+0

마크와 동의. "숨겨진"공용 메소드 및/또는 내부를 만들 필요없이 공용 인터페이스를 통해 모든 코드를 테스트 할 수 있어야합니다. –

+0

@Mark 회귀 테스트를 돕기 위해 [공용 인터페이스를 통해 코드 테스트] (http://stackoverflow.com/questions/856115)입니다. (public, documented) 입력 이벤트 후에 테스트 케이스가 (문서화되지 않은) 내부 상태를 선언 할 수 있도록합니다. – ChrisW

답변

0

두 가지 가능성은 InternalsVisibleTo 및/또는 반사입니다. 나는이 아이디어를 선호하는 강한 이유를 전혀 모르고있다.

6

internal/InternalsVisibleTo 좋은 방법이지만 여전히 컴파일 된 코드에서 메소드를 생성하므로 리플렉션을 통해 사용할 수 있습니다.

테스트 방법을 추가하는 단위 테스트에만 조건부 컴파일 기호를 사용할 수 있으며 릴리스 버전을 빌드 할 때 해당 기호를 정의하지 않아도됩니다. 그런 식으로,이 메소드는 "Test"구성에서 빌드되지 않을 때 존재하지 않습니다.

+0

+1은 과거와 마찬가지로 가장 쉬운 방법으로 이처럼 기호를 사용했습니다. –

+0

나는 반사를 사용하는 해커에 대해 신경 쓰지 않는다; 컨트롤의 일반 소비자가 문서화되지 않은 메서드를 보지 않기를 바랄뿐입니다. 또한 조건부 컴파일은 [릴리스 버전 테스트] (http://stackoverflow.com/questions/420343) 때문에 작동하지 않습니다. – ChrisW

+0

추가 메서드를 사용하여 릴리스 버전과 다른 구성 만 만들면 결국 동일하게 끝납니다. 다른 심볼을 정의하기 위해 디버그 구성에있을 필요는 없습니다. – CMerat

0

필자는 개인적으로 컴파일러 스위치를 사용 하겠지만, 단위 테스트 코드에서 항상 리플렉션을 사용하여 비공개 멤버에게 접근 할 수 있습니다.

+0

내가 [릴리스 빌드 테스트] (http://stackoverflow.com/questions/420343)를 원하기 때문에 조건부 컴파일을 사용하지 않는다는 것을 감안할 때, 리플렉션을 사용하는 것이 더 좋은지 또는 ' InternalsVisibleTo' 속성? – ChrisW

+0

두 버전의 코드 사이의 유일한 차이점은 메서드를 개인에서 공용으로 변경하는 서명이 될 경우 문제가 될 정도로 테스트 범위에 영향을주지 않는다고 주장합니다. 무엇이든 깨지면 컴파일러가 어쨌든 그것을 잡을 것입니다. 나는 반사 작용을 사용할 것입니다 - 그것의 내부와 당신은 그렇게 정착하는 것을 원하지 않습니다. –

관련 문제