컨트롤러에 대한 단위 테스트를 작성하는 이유는 무엇입니까?


22

나에게 이것은 완전히 관련이없는 단위 테스트이며 누군가가 왜 그것을 쓸 가치가 거의 없기 때문에 그것을 작성하는 데 시간을 소비했는지 이해하지 못합니다. 이 컨트롤러가 브라우저에서 메소드를 실행하여 원하는 유형을 반환하면 완벽하게 알 수 있습니다. 실제로, 당신은 이것에 대한 시험이 필요하다고 생각합니까?

public class ConstituencyControllerTests
{
    private ConstituencyController _constituencyController;
    private Mock<IConstituencyService> _IConstituencyServiceMock;

    public ConstituencyControllerTests() {
        _IConstituencyServiceMock = new Mock<IConstituencyService>();
    }

    [Test]
    public async Task I_Check_For_Return_Type_And_Result() {
        _constituencyController = new ConstituencyController( _IConstituencyServiceMock.Object );

        var result = await _constituencyController.Get();
        var content = ( (dynamic)result ).Content;

        Assert.IsEmpty( content );
        Assert.IsInstanceOf( typeof( System.Web.Http.Results.OkNegotiatedContentResult<IEnumerable<ListOfConstituencies>> ), result );
        _IConstituencyServiceMock.Verify( x => x.ListOfConstituencies(), Times.Once() );
    }
}


7
@gnat에 동의하지 마십시오. 이것은 언어 구성에 관한 것이 아니라 컨트롤러가 반환 한 결과의 유형에 관한 것입니다. 상속 계층 구조가 없을 때 같은 종류의 것으로 분류 될 수 있지만 컨트롤러가 조상을 반환하고 컨트롤러가 Person을 반환하면 Person은 Ancestor가 아닌 PeopleAncestor로 변경됩니다. ... 또한 그러한 방법을 테스트하는 것이 좋은 아이디어가 될 수있는 이유에 대한 답변입니다. ...;) 단위 테스트는 한 가지 변화가 다른 것을 깨뜨릴 수있는 상황을 포착하기위한 것입니다.
Marjan Venema


동의하는 경향이 있습니다. 저는 일반적으로 신청서의 진입 점을 테스트하는 데 많은 시간을 소비하지 않습니다. 콘솔 응용 프로그램의 주요 방법을 단위로 테스트하는 것과 같습니다. 나에게는 거의 이해가되지 않습니다.
Mvision

답변:


29

핵심은 다음과 같습니다.

이 컨트롤러가 브라우저에서 메소드를 실행하여 원하는 유형을 반환하면 완벽하게 알 수 있습니다.

단위 테스팅은 단순한 코드 단위가 아닌 비 회귀 테스트 자동화 에 관한 것입니다. 응용 프로그램에서 항상 단위 테스팅을하고 싶지는 않습니다.

편집 : @anotherdave 의견 추가 :

확장의 용이성에 관한 것입니다. 브라우저에서 하나의 컨트롤러를 테스트해도 괜찮습니다. 컨트롤러 10, 20, 50은 어떻습니까? 테스트를 한 번 작성합니다. 컨트롤러를 교체 할 때 업데이트해야 할 수도 있습니다. 그러나 얼마나 자주 배포합니까? 테스트보다 훨씬 많은 오버 헤드가있을 때마다 수동 점검

@Vladislav의 답변에 대한 대안으로 , 단위 테스트는 모든 것을 절대적으로 과도하게 할 수 있으며 실제로 바람직하지 않습니다. 더 가벼운 것이 필요한 경우 Selenium을 사용하여 더 높은 수준의 비 회귀 테스트를 수행 할 수 있습니다. 물론 단위 테스트보다 적용 범위가 줄어들지 만 단위 테스트를 수행하는 데 시간이 덜 걸리고 더 융통성있는 커버리지를 얻을 수 있습니다.

즉, 모든 것을 단위 테스트하는 경우 간단한 요소를 수정할 때마다 하나 이상의 테스트를 업데이트해야합니다.


4
또한 re :를 추가하면 I would know perfectly well if this controller returned the wanted type by executing the method in a browser.확장이 쉬워집니다. 브라우저에서 하나의 컨트롤러를 테스트해도 괜찮습니다. 컨트롤러 10, 20, 50은 어떻습니까? 테스트를 한 번 작성합니다. 컨트롤러를 교체 할 때 업데이트해야 할 수도 있습니다. 그러나 얼마나 자주 배포 합니까? 테스트보다 훨씬 많은 오버 헤드가있을 때마다 수동으로 확인하십시오.
anotherdave

"단위 테스팅은 자동화에 관한 것"-맞습니다. 그러나 통합 테스팅도 마찬가지입니다 (Selenium / Webdriver / etc.). 단위 테스트가 통합 테스트보다 구현하는 것이 더 빠르다고 생각할 필요는 없습니다. 접근 방식에 따라 크게 달라 지지만 효과적인 단위 테스트를 수행하려면 서로 다른 서비스와 호출을 수십 가지로 모방해야하는 경우 통합 테스트가 구현 속도가 빠르고 유지 관리가 더 간단 할 수 있습니다 (일반적으로 실행 속도가 훨씬 느리지 만) . 요점은 컨텍스트와 테스트중인 코드의 복잡성에 따라 달라집니다.
aroth

@anotherdave 댓글이 추가됨
Walfrat

@aroth 내 요점은 반대였습니다. 전체 단위 테스트 코드는 많은 시간이 걸리고 단위 테스트를 변경하지 않고도 코드를 변경하기가 매우 어렵습니다. 통합 테스트는 더 가볍습니다. 물론 단위 테스트는 매우 복잡한 것을 원하지만 그 부분을 단위 테스트했기 때문에가 아니라 모든 것을 단위 테스트해야합니다. 다시 우리는 사람들이 존재하지 않는 은색 총알을 검색하는 것을 봅니다.
Walfrat

24

컨트롤러에 대한 단위 테스트를 작성하는 이유는 무엇입니까?

컨텍스트를 알지 못하면 이것을 테스트 해야하는지 확실하게 말할 수 없기 때문입니다. 컨트롤러를 테스트해야하는 이유는 다음과 같습니다.

  • 컨트롤러는 복잡한 서비스 배선 로직을 포함 할 수 있으며 오류가 발생하기 쉽습니다. 서비스 자체가 제대로 작동 할 수 있습니다. 테스트하려는 결과이며 어떤 이유로 든 오케스트레이션 계층을 앱에 도입하지 않기로 고려했습니다.
  • 귀하의 컨트롤러에는 응용 프로그램의 전체 비즈니스 로직이 포함되어 있으며 컨트롤러는 실제로 테스트 할 수있는 모든 것입니다 (이상적인 코드베이스로 작업 한 모든 삶을 그런 척하지 마십시오.
  • 당신의 팀은 99 %의 천재와 평균적인 사람들의 1 %로 구성되어 있습니다.

2
"앞으로 누가 프로젝트를 제거 할 것인지 예측할 수 없으며 테스트는 자체 문서화 된 코드의 일부입니다"
Laiv

4
중간 테스트를 염두에두고 작성된 프로젝트는 모의가없는 컨트롤러 테스트 이외의 다른 방법으로는 테스트 할 수 없습니다. 저는 관리 프로젝트에 정확히 그러한 프로젝트가있는 C # 팀과 함께 작업하므로 세밀한 테스트에 필요한 구조 (인터페이스 등)를 추가 할 수있을 때까지 컨트롤러 테스트를 작성합니다.
Wayne Conrad

1

OP에 동의합니다.

컨트롤러의 단위 테스트는 의미가 없습니다. 회귀 테스트를 통해 컨트롤러를 암시 적으로 테스트합니다 (예 : Selenium 사용).

컨트롤러가 사용하는 모든 구성 요소 / 객체를 TDD하고 컨트롤러를 가능한 한 얇게 유지해야합니다. 그런 다음 모든 것이 올바르게 단위 테스트됩니다. 당신이 확신하고 싶은 것은 웹 요청을 수행 할 때 모든 것이 잘 작동한다는 것입니다. 그것은 회귀 테스트입니다.


어쩌면 그럴 수도 있지만 그것은 질문에 대한 답이 아닙니다. 사실, 여기서는 단위 테스트 사용에 대한 논쟁입니다.
JᴀʏMᴇᴇ

나는 "당신은 이것에 대해 시험이 필요하다고 생각합니까?"라는 질문에 대답했다고 생각합니다.
winkbrace

예, @winkbrace와 같은 생각을합니다. 그러나 나는 또한 단위 테스트가 아닌 무엇을 해야하는지에 대한 토론이라고 믿습니다. 나는 사람들이 너무 많이 테스트하고 "잘못된"것을 생각합니다. 내 예제에서 컨트롤러 테스트는 너무 얇고 서비스를 둘러싼 테스트가 있기 때문에 거의 가치가 없습니다. 여기에있는 모든 대답은 의미가 있고 좋은 점이 있지만 실제로 정답으로 표시하는 것은 불가능합니다.
frostings

컨트롤러 로직은 자동화 된 통합 테스트를 사용하여 개별 구성 요소에 대한 단위 테스트와는 별도로 테스트 할 수 있습니다.
KevBurnsJr

-1 : 컨트롤러에 대한 단위 테스트가 의미가 없을 수 있습니다. 컨트롤러는 변환에 관한 것이지만 때로는 변환 자체가 복잡하여 개발자가 다루기를 원할 수도 있습니다. 또한 단위 테스트 1) 궁극적으로 구현의 유효성을 확인하는 것이지 반드시 상위 수준의 동작을 확인하는 것은 아니며 2) 빠르다고 생각합니다 . 두 가지 특성 모두 구현 시간 동안 단위 테스트를 훨씬 더 유용하게 만듭니다. 다시 말해, 이들은 궁극적으로 개발자의 도구이며 우연히 제품 품질을 검증하는 방법입니다.
rsenna 2016 년
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.