테스트 할 수없는 것이 있습니까?

Question

단위 테스트의 경우 프레임 워크가 얼마나 낮은 지 알면 항상 어렵습니다.

우리가 .NET Framework, 즉 System.IO.File 클래스에 직접 의존하는 클래스를 갖고 있다면 실제로는 테스트 할 수 없습니다.

물론이 클래스를 종속 클래스에 넣을 수는 있지만 모든 .NET 클래스를 래핑하기 시작합니다. 래퍼가 곧바로 통화하지 않으면 어떻게 될까요? 어쩌면 테스트/비즈니스 로직을 먼저 수행 할 것인가?

현재 특정 수준까지 랩핑 한 다음 래퍼 단위 테스트를 방해하지 않습니다. 나중에 통합 및 탐색 테스트를 통해 테스트 될 것이므로 아마도 괜찮을 것입니다.

이 클래스는 단단히 .NET 프레임 워크에 연결되어

.. 잘 먹으 렴하지만 지금은 격리에서 테스트 어차피,이 등 존재하는 파일이 필요합니다 : 여기

그냥 내 지점을 설명하기 위해 C#의 예입니다 . 같은 것을 수행하여

우리가 할 수있는

public class PathResolver 
{ 
    public string Resolve(string filename) 
    { 
     string completePath = string.Empty; 
     if(!File.Exists(filename)) 
     { 
      return Path.Combine(@"D:\MyExample", filename); 
     } 
     return completePath; 
    } 
} 

단위 테스트이 :

public class PathResolver 
{ 
    private readonly IFileSystem _fileSystem; 

    public PathResolver(IFileSystem fileSystem) 
    { 
     _fileSystem = fileSystem; 
    } 

    public string Resolve(string filename) 
    { 
     string completePath = string.Empty; 
     if(!_fileSystem.Exists(filename)) 
     { 
      return _fileSystem.Combine(@"D:\MyExample", filename); 
     } 
     return completePath; 
    } 
} 

하지만 지금 우리는 "파일 시스템"클래스를 테스트하지 못할!

다른 사람들의 생각은 무엇입니까?

Answer 1

실제로 어느 시점에서 IFileSystem과 같은 인터페이스를 구현해야하므로 응용 프로그램을 .NET 프레임 워크에 붙일 수 있습니다. 이 "glue-code-in-between"은 단위 테스트를 할 수 없습니다. 이것은 접착제 코드가 매우 단순한 한 많은 문제가 아닙니다.

접착제 코드가 원하는만큼 간단하지 않은 경우에도 자동화 통합 테스트을 사용할 수 있습니다. 일종의 자체 테스트 모드에서 조립 된 응용 프로그램을 실행하십시오.

단위 테스트가 더 자주 사용되는 이유는 생성이 쉽고 부서지기 쉽지 않기 때문입니다. 단위 테스트를 실행하기 위해 데이터베이스, 웹 서버 또는 파일 시스템을 준비 할 필요가 없습니다. 클래스 B를 변경하면 클래스 A의 단위 테스트에 대해 걱정할 필요가 없습니다. 통합 테스트는 더 많은 것들을 테스트 할 수 있지만 이러한 장점은 없습니다.

Answer 2

일반적으로 .NET과 같은 테스트 프레임 워크는 사용자의 책임이 아니라 프레임 워크를 릴리스하는 사람들의 책임입니다.

Answer 3

System.IO를 테스트 하시겠습니까? 그렇지 않다면 왜 의존성을 없애기 위해 조롱/스터핑 방식을 사용하지 않을까요?

Answer 4

종속성 삽입을 사용하는 경우 클래스의 외부 호출이 외부 라이브러리가 아닌 스텁을 향하도록 할 수 있습니다.

Answer 5

단위 테스트를 할 때 불행히도 애플리케이션의 모든 것을 테스트 할 수 없습니다. 이것이 테스트를 할 때 테스트가 프로젝트에 대해 90 %의 코드 커버리지를 수행하는 것을 목표로하는 이유입니다. 이 테스트의 작업이

Answer 6

그것은 전체 프레임 워크 의존성을 스텁 필요는 없습니다 오히려 비용이 많이들 수 있기 때문에

하여 통합 테스트 또는 엔드 - 투 - 엔드 테스트도 일부의 일환으로이 테스트를 수행 - 당신의 코드를 단위 테스트하는 능력을 방해하는 부분들. 따라서 데이터베이스 호출과 함께 System.IO.File 작업을 자유롭게 작성해야한다고 생각합니다. 또한 DateTime.UtcNow를 호출하는 대신 IClock 인터페이스를 사용하여 시간을 알려주는 것이 매우 유용하다는 것을 알았습니다. 이렇게하면 단위 테스트에서 시간 경과를 제어 할 수 있습니다.

Answer 7

아래의 프레임 워크가 아니라 클래스를 테스트하면됩니다.

이 경우 테스트 케이스를 설정하는 테스트 드라이버가 필요합니다. 예를 들어 해결할 파일을 만들고 클래스를 인스턴스화하고 작업을 수행하십시오.

좋은 테스트 드라이버는 테스트 시나리오도 정리하고 시스템을 테스트 전과 동일한 상태로 둡니다.

Answer 8

클래스를 테스트 할 수는 없지만 격리 프레임 워크 (Rhino Mocks, Typemock, Moq)를 사용하여 조롱 할 수있는 경우 "테스트 할 수없는"클래스의 세부 사항을 속일 수 있습니다.

Answer 9

이것은 단위 테스트와 통합 테스트의 차이점을 보여주는 좋은 예입니다. 단위 테스트 PathResolver의 경우 손으로 또는 모의 프레임 워크 (예 : 내 즐겨 찾기 Moq)를 사용하여 만든 모의 객체를 전달해야합니다. mock 객체를 사용하면 Combine 메서드가 호출되었는지 테스트 할 수 있습니다.

[Test] 
public void ShouldCombinePath() 
{ 
    IFileSystem fs = new Mock<IFileSystem>(); 

    PathResolver resolver = new PathResolver(fs.Object); 

    resolver.Resolve("Test.filename"); 

    fs.Verify(fs => fs.Combine()); 
} 

단위 테스트가 외부 종속성없이 빠르게 실행되도록되어 있습니다 :

단위 테스트는 다음과 같이 (MOQ를 사용하여)을 볼 것이다. 그들은 모든 컴파일마다 호출되어야합니다.

하지만 맞습니다. 구체적인 클래스를 테스트해야합니다. 이것이 통합 테스트입니다. "MyProject.IntegrationTest"라는 별도의 프로젝트를 만들고 프로젝트에 포함 된 테스트 파일을 사용하여 SystemFileSystem을 직접 테스트하는 것이 좋습니다.

통합 테스트는 지속적인 통합 소프트웨어를 사용하여, 커밋 새로운에서 소프트웨어의 빌드를 만들 때 일반적으로 불리는이

[Test] 
public void ShouldCombinePath() 
{ 
    DotNetFileSystem fileSystem = new DotNetFileSystem(); 

    string resultPath = fileSystem.Combine("Test.filename"); 

    Assert.That(resultPath, Text.Contains("@D:\MyExample\Test.filename")); 
} 

통합 테스트처럼 보일 것입니다. 외부 종속성을 사용하기 때문에 속도가 느려질 수 있습니다.