2012-02-02 5 views
3

단위 테스트에서 다음과 같은 .net 구성 파일 (예 : app.config 및 web.config)의 정보에 액세스하는 데 문제가 있습니다. 호스트 유형 "몰". 그것은 몇 가지 두통을 일으키는 것이므로 누군가에게 무엇을 할 수 있는지에 대한 아이디어가 있기를 바랍니다.테스트에 호스트 유형 "Moles"가있을 때 구성 파일의 정보에 액세스 할 수 없음

우리는 Visual Studio 2010을 사용하고 있으며 VS 2010 SP1이 설치된 컴퓨터와 SP1이 설치되지 않은 컴퓨터에서이 작업을 시도했으며 32 비트 및 64 비트 컴퓨터에서도이 작업을 시도했습니다.

나는 테스트를 가장 간단한 조건으로 줄이는 데 자유를 사용했습니다. 다음 두 파일로 구성된 단위 테스트 프로젝트를 작성하고 주석 처리 된 행의 주석을 제거한 후 테스트를 실행하여 문제를 재현 할 수 있습니다. 이 테스트는 호스트 유형없이 수행되지만, Mole을 호스트 유형으로 도입하면 테스트에서 널 어설 션이 실패합니다. 이유는 확실하지 않습니다.

첫째, 구성 파일의 App.config :

<?xml version="1.0"?> 
<configuration> 
    <connectionStrings> 
    <add name="Connection" connectionString="Something" /> 
    </connectionStrings> 
</configuration> 

다음, 단일 테스트를 포함하는 테스트 클래스 :

namespace TestProject 
    { 
    using System.Configuration; 
    using Microsoft.VisualStudio.TestTools.UnitTesting; 

    [TestClass] 
    public class UnitTest 
     { 

     [TestMethod] 
     //[HostType("Moles")] 
     public void TestMethod() 
      { 
      var data = ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None); 
      Assert.IsNotNull(data.ConnectionStrings.ConnectionStrings["Connection"]); 
      } 

     } 

    } 

사람이 어떤 통찰력을 제공 할 수 있다면 나는 감사 드리겠습니다. 이 일을 할 것입니다 경우

정말 감사합니다,

+0

UnitTest 프로젝트의 App.Config를 HostType ("Moles")을 사용하여 테스트하는 방법 (http://stackoverflow.com/questions/4105604/how-to-read-unittest-projects-app- config-from-test-with-hosttypemoles) – NotMe

+0

또한 http://stackoverflow.com/questions/8859087/moles-v0-94-causing-tests-to-ignore-config-file에서 비슷한 질문을 봅니다. – sfuqua

답변

1

는 잘 모르겠어요,하지만 당신은이 해결 방법을 시도 할 수 있습니다 : 파일 매핑을 사용하여 설정을 엽니 다. 코드는 다음과 같이 표시됩니다

ExeConfigurationFileMap fileMap = new ExeConfigurationFileMap(); 
fileMap.ExeConfigFilename = configurationFilePath; 
System.Configuration.Configuration configuration = 
    ConfigurationManager.OpenMappedExeConfiguration(
     fileMap, 
     ConfigurationUserLevel.None); 
1

당신이 단위 테스트, 응용 프로그램 및 사용자 설정은 의존성 주입을 통해 전달해야을 수행하는 모든 시간을. 이것은 쉽게 할 수있는 설정을위한 스텁을 작성하여 수행됩니다.

  1. 모든 구성 설정에 대한 속성을 포함하는 테스트중인 프로젝트에서 인터페이스를 만듭니다. 참조 할 수 있도록이 "ISettings"라고합니다.

  2. 인터페이스를 구현하는 대상 어셈블리에서 스텁 (클래스)을 만듭니다. 스텁의 각 속성에는 구성 파일에서 해당 설정을 반환하는 get 만 포함해야합니다. 이 스텁을 "SettingsStub"라고 부릅니다. 이 스텁은 프로덕션 환경에서 대상 어셈블리에서 사용됩니다.

  3. 대상 형식 (테스트 할 클래스) 생성자에 형식화 된 ISettings 인수를 추가합니다. 대상 클래스의 필드는 생성자에 전달 된 ISettings 개체로 설정해야합니다. 오버로드 생성자를 만들고 일부 디자인 패턴 (MVVM 등)에서 필요에 따라 기본 생성자를 유지할 수 있습니다. 인수가없는 기본 생성자는 프로덕션에 사용하기 위해 새 SettingsStub를 인스턴스화 할 수 있습니다. 오버로드 된 생성자는 항상 테스트에서 사용해야합니다!

  4. 테스트 프로젝트에 설정 스텁을 만들고 ISottings도 구현합니다. 이것을 TestSettingsStub라고 부릅니다. 이 스텁에는 대부분의 테스트에서 허용되는 하드 코딩 된 값이 들어 있습니다.

  5. 대상 및 테스트 프로젝트를 다시 빌드하십시오. Moles는 SISettings라는 스텁 유형을 생성합니다.

설정 값을 조정할 필요가없는 경우 콘크리트 TestSrtyingsStub를 사용하십시오. 또는 하나 또는 두 번의 테스트를 위해 값을 조정해야하는 경우 Miles Stub 유형을 사용하십시오. Moles Stub 유형의 목적은 하나 또는 두 개의 고유 한 변경 사항을 포함하는 많은 스텁을 작성할 필요를 피하기위한 것입니다.

오버로드 된 생성자를 호출 할 때 SettingsStub, TestSettigsStub 및 SISettings 형식은 서로 바꿔서 사용할 수 있습니다. 이제는 테스트 중에 로직을 전환하거나 수동으로 설정 값을 변경하지 않고도 각 컨텍스트에서 사용되는 설정을 완전히 제어 할 수 있습니다. 대상 코드는 구성 파일에서 직접 설정하는 대신 로컬 필드에서 설정 값을 간단히 검색합니다. 의존성 주입 및 Inversion of Control (IOC) 주제를 참조하십시오.

일반적으로 개발 워크 스테이션 개발은 안전을 위해 프로덕션 네트워크의 외부 종속성 시스템 (데이터베이스 등)에 액세스 할 수 없습니다!

해피 코딩!

+0

downvoting 때문에 while 포인트 1은 좋고, 그 이상은 아무것도 아닙니다. 그런 종류의 접근법에 비해 두발은 과도하게 훌륭하며 의도 한 바가 전혀 아닙니다. 이 경우 Moq과 같은 간단한 mocking 프레임 워크로 충분합니다. * 모의 할 수없는 코드에는 반드시 첩구를 사용해야합니다. 파일 시스템 액세스, 데이터베이스 호출 등 ... 통합 테스트보다는 단위 테스트로 진행됩니다. – dotnetnate

+0

@dotnetnate 간단한 의존성 주입의 경우 조롱 프레임 워크를 사용하는 것을지지하지 않습니다. 그러나 이미 사용중인 조롱 프레임 워크의 스터 빙 기능을 사용하는 데는 아무런 문제가 없습니다. –

+0

@ dotnetnate Moles를 사용하는 것이 테스트에서 사용하기에 좋지 않은 방법이라고 생각하지 않습니다. 그것은 결국 조롱과 스터 빙 프레임 워크입니다. 저도 Moq을 사용하는 것이 더 쉽다고 말하고 싶습니다. 왜냐하면 단일 람다를 통해 우회 도로를 작성하는 것이 Moq 객체를 작성하는 것보다 빠르며 동일한 목적을 달성하기 때문입니다. 이미 두 사람이 같은 일을 할 때, 두 사람이 이미 두 사람을 고용하고있을 때 왜 모크를 사용해야합니까? –

0

나는 마이크의 대답이 논리적으로 정확하다는 데 동의한다. (잠재적으로 클래스에서 로딩 구성을 분리하지 않는다.) 실용적인 문제는 Moles 호스트 유형에 대해 원래 질문마다 구성 시스템에 대한 호출을 몰수하는 것, 예.

MConfigurationManager.AllInstances.OpenExeConfiguration (... finish your moleing here...) 

구문은 대략 - 당신은이 경우에 SConfigurationManager 또는 MConfigurationManager로 끝날 경우 내가 기억할 수 없습니다.

전적으로 마이크와 동의하지 않습니다. "개발 워크 스테이션은 외부 의존성 시스템에 액세스 할 수 없습니다 ..."라는 말은 끔찍한 충고입니다. 우리는 이러한 것들을 통합 테스트라고합니다.

예, 개발자가 작성해야합니다. 어느 시점에서 구체적인 구현 (예 : 데이터베이스, 백업 서비스 등)에 접하는 코드를 작성하고 해당 상호 작용을 테스트하지 않으면 거의 잘못하고있는 것입니다.

+0

유닛 테스트는 타겟 코드 만 테스트하는 것으로되어 있습니다. 통합 테스트는 다른 코드 및 외부 리소스와의 상호 작용을 테스트해야합니다 (저는 바보가 아닙니다). 나는 이것이 단위 테스트와 통합 테스팅에 관한 질문이라는 인상 아래에있었습니다. 이것이 단위 테스트의 질문이라면, 당신은 "끔찍한 충고가 될 것입니다." 단위 테스트와 통합 테스트는 상호 배타적입니다. 또한 나쁜 조언을 똑같이 분배 할 수있을 때 다른 사람을 격추 할 필요가 없습니다. –

+1

답장을 읽어주십시오. 실제로 우리는 서로를 더 신중하게 읽어야합니다. 단위 테스트와 통합 테스트를 명확히 구분했습니다. 내 오류는 귀하의 조언 중 "생산 네트워크"부분을 읽는 데있었습니다. 크게 대화와 관련이 없으며 잠재적으로 과부하 된 용어이지만 사지에 서서 단순히 프로덕션 SOR을 목표로한다고 가정합니다. – dotnetnate

+0

동의합니다. 컨텍스트는 의사 소통에 다소 지장이 있습니다. 잘 했어. 너에게 내 모자를 기울인다. 선생님. –