MVC 뷰 테스트가 왜 눈에 띄는가?

23

현재 ASP.Net MVC 응용 프로그램의 기초를 설정 중이며 어떤 종류의 단위 테스트를 작성해야하는지 조사 중입니다. 나는 사람들이 본질적으로 '여러분의 견해를 테스트하지 않고 논리가 없으며 사소하고 통합 테스트에 의해 다루어 질 것입니다'라고 말하는 곳을 여러 곳에서 보았습니다.

이것이 어떻게 받아 들여지는 지혜가되었는지 이해가되지 않습니다. 통합 테스트는 단위 테스트와 완전히 다른 목적으로 사용됩니다. 무언가를 망가 뜨리면 30 분 후에 통합 테스트가 중단 될 때 알고 싶지 않아 즉시 알고 싶습니다.

샘플 시나리오 : Customer 엔터티와 함께 표준 CRUD 앱을 처리한다고 가정합니다. 고객의 이름과 주소가 있습니다. 각 테스트 수준에서 고객 검색 로직이 이름과 주소를 올바르게 가져 왔는지 확인하고 싶습니다.

저장소를 단위 테스트하기 위해 데이터베이스에 충돌하는 통합 테스트를 작성합니다. 비즈니스 규칙을 단위 테스트하기 위해 리포지토리를 모의하고 비즈니스 규칙에 적절한 데이터를 제공하며 예상 결과가 반환되는지 확인합니다.

내가하고 싶은 일 : UI를 단위 테스트하기 위해 비즈니스 규칙을 모의하고 예상 고객 인스턴스를 설정하고 뷰를 렌더링하고 뷰에 지정된 인스턴스에 대한 적절한 값이 포함되어 있는지 확인합니다.

내가 저지른 일 : 저장소를 단위 테스트하기 위해 통합 테스트를 작성하고, 적절한 로그인을 설정하고, 데이터베이스에 필요한 데이터를 작성하고, 브라우저를 열고, 고객을 탐색하고, 결과 페이지에 적절한 것이 포함되어 있는지 확인하십시오. 내가 지정한 인스턴스의 값.

위에서 설명한 두 시나리오 간에는 중복이 있지만 테스트를 설정하고 실행하는 데 시간과 노력이 얼마나 큰 차이가 있는지 알고 있습니다.

내가 (또는 다른 개발자가)보기에서 주소 필드를 제거하면 통합 테스트가이를 발견하기를 기다리지 않습니다. 나는 매일 여러 번 얻는 단위 테스트에서 발견되고 표시됩니다.

핵심 개념을 이해하지 못한다는 느낌이 들었습니다. 누군가 MVC 뷰의 유효성에 대한 즉각적인 테스트 피드백을 원하는 것이 나쁜 이유를 설명 할 수 있습니까? (또는 나쁘지 않은 경우, 피드백을 얻는 예상 방법이 아닙니다)

unit-testing asp.net-mvc

— 피터 버니어
소스

1

"To unit-test the repository, I write an integration test"무엇을 기다립니다? 그것은 저장소의 단위 테스트가 아닙니다. 테스트를 자동화하고 있지만 테스트중인 코드에는 여전히 DAL과 데이터베이스가 포함되어 있습니다. 저장소를 단위 테스트하려면 비즈니스 규칙과 같이 저장소를 분리하십시오.

— StuperUser

예상대로 렌더링 된 뷰를 단위 테스트하는 것은 템플릿 엔진이 작동하는 단위 테스트입니다. 컴파일 된 C에는 특정 코드의 기계 코드가 포함되어 있으며 단위는 컴파일러가 아닌 코드를 테스트합니다.

— Raynos

2

@Raynos 존경스럽게, 나는 동의하지 않을 것이다. 내가 (또는 다른 개발자)가 실수로 UI를 연결하여 UI 필드에서 하나의 데이터 속성을 다른 데이터 필드로 렌더링하는 경우 (예 : 'Last Name Field'의 'First Name'), 템플릿 엔진과 관련이 없으며 그것은 DAL 또는 BR 문제입니다. 그것은 단지보기에만 노출 될 문제입니다

— Peter Bernier

1

@PeterBernier 좋은 지적이 있지만 "컴파일러 작동 여부 테스트"와 "코드 작동 여부 테스트"사이의 선을 정의하기가 어렵다는 것을 알았습니다. UI 테스트는 UI와 밀접하게 연결되어 있습니다. UI를 변경하면 테스트가 실패합니다. 테스트에 실패하지 않으면 서 UI를 리팩토링 할 수 없습니다.

— Raynos

9

간단한 UI 테스트는 ASP.NET MVC에서 충분히 쉽습니다. 본질적으로 당신이해야 할 일은 반환 된 HTML에 필요한 요소가 포함되어 있는지 확인하는 것입니다. 이렇게하면 HTML 페이지가 원하는 방식으로 구성되지만 UI를 완전히 테스트하지는 않습니다.

올바른 웹 UI 테스트에는 컴퓨터에서 브라우저를 사용하고 모든 브라우저에서 JavaScript 및 HTML이 올바르게 작동하는지 확인하는 Selenium과 같은 도구가 필요합니다. Selenium에는 클라이언트 / 서버 모델이 있으므로 Unix, Mac 및 Windows 클라이언트가있는 가상 머신 세트와 해당 환경에 공통된 브라우저 세트를 가질 수 있습니다.

이제 잘 설계된 MVC (프레임 워크가 아닌 패턴) 애플리케이션은 모델과 컨트롤러에 중요한 논리를 적용합니다. 간단히 말해이 두 가지 측면을 테스트 할 때 응용 프로그램 기능이 테스트됩니다. 뷰 는 디스플레이 로직 만있는 경향이 있으며 육안 검사로 쉽게 확인할 수 있습니다. 뷰의 얇은 처리와 잘 테스트 된 많은 애플리케이션으로 인해 많은 사람들은 뷰 레이어 테스트의 어려움이 뷰 레이어의 이점을 능가한다고 생각하지 않습니다.

즉, MVC에는 요청에 의해 반환 된 DOM을 확인하는 멋진 기능이 있습니다. 뷰 레이어를 테스트 할 때 고통이 상당히 줄어 듭니다.

— 베린 로리 치
소스

1

"반드시 필요한 것은 반환 된 HTML에 필요한 요소가 포함되어 있는지 확인하는 것입니다." 이것은 내가하려고하는 일이며 사소하지 않은 것으로 판명되었습니다. 단순히 컨트롤을 렌더링하는 대신 특정 컨트롤러 작업으로 작동하는 링크를 가리킬 수 있습니까? (저는 몇 가지 글을 썼지 만 RenderPartial은 상당한 오버 헤드없이 내가하고 싶은 일을 달성하지 못했습니다.)

— Peter Bernier

mvccontrib.codeplex.com (MVC Contrib) 을 확인하십시오 . 핵심 언어로 작성되지 않았으며 "Test-Drive ASP.NET MVC"(실용적인 프로그래머) 책에서 권장되는 도움말을 제공합니다. 그래도 Selenium이 View 테스트에 더 적합하다고 생각합니다.

— Berin Loritsch

TestHelper (MVC Contrib) : mvccontrib.codeplex.com/…

— Berin Loritsch 2016 년

Selenium (내 경우에는 Selenium RC)은 통합 테스트에 사용할 것입니다. 내가 원하는 것은 그 시점 이전에 실패가 발생하는 것입니다.

— 피터 버니어

2

@Peter : "사소하지 않은"노력에 대한 귀하의 의견은 단위 테스트 관점이 찌그러지는 이유입니다. 결과적으로 일반적인 전략은 뷰를 가능한 한 얇게 (즉, 비즈니스 로직을 포함하지 않음) 만들어서 대부분의 단위 테스트를 다른 곳 (일반적으로 ViewModel)에서 수행 할 수 있도록하는 것입니다. 뷰 자체는 육안 검사 또는 Selenium과 같은 UI 테스트 도구로 확인할 수 있습니다.

— Robert Harvey

7

나는 눈살을 찌푸리게 말하지 않을 것이다. 오히려 그 감정은 aspx 뷰가 WebForms에 너무 많은 의존성을 가지기 때문에 단위 테스팅 MVC 뷰 (적어도 aspx 종류)가 상당히 어렵다는 사실의 결과입니다. 따라서 견해가 그렇게 복잡하지 않은 경향이 있기 때문에 노력할 가치 가 없다는 주장이 계속 됩니다.

물론보기는 매우 복잡 할 수 있으므로 선택해야합니다.

— 마르 신드
소스

3

내가 아는 한 ASP.NET MVC 뷰는 Webform과 관련이 없습니다. Webforms가 아닌 ASP.NET MVC의 큰 장점 중 하나가 아닙니까?

— Adam Lear

내 관점은 UI를 다루기 위해 통합 테스트를 작성하는 데 더 많은 노력이 필요하다는 것입니다.보기를 다루기 위해 실제 '단위 테스트'를 작성하는 것보다 그렇습니다. 그렇기 때문에 견해에 대한 단위 테스트 작성에 대한 저항의 일부를 이해하려고합니다.

— 피터 버니어

@Anna Aspx보기는 WebForms를 기반으로합니다. System.Web.UI.WebControls.Page클래스 에서 파생되고 <asp:ContentPlaceholder>컨트롤 등을 사용 합니다. MVC가 실행하는 방식은 일반적으로 WebForms와 관련된 많은 페이지 실행 파이프 라인을 피하지만 여전히 커버 아래에 많은 WebForms 항목을 사용합니다.

— marcind

다른보기 엔진 (예 : 면도기)을 사용하는 경우 Webforms 엔진에서 더 멀리 이동할 수 있어야합니다.

— 머핀 맨

6

나는 그것이 눈살을 찌푸리게 확실하지 않다. 테스트 가능성은 ASP.NET MVC 사용의 주요 이점 중 하나입니다. 이에 대한 자세한 내용은 Steve Sanderson의 블로그 를 확인하십시오 .

그는 또한 핸드 다운, 최고의 ASP.MVC 책 (IMO)을 썼습니다 . 그는 MVC를 가르치는 것뿐만 아니라 테스트 관행을 포함하여 MVC를 둘러싼 모범 사례를 가르치기 위해 계속 노력하고 있습니다.

단위 테스트 뷰를 조금 명확히해야한다고 생각합니다. 컨트롤러에서 반환 된 결과 (ActionResult 등)에 대해 단위 테스트를 작성할 수 있습니다. 실제 UI 및 UI 상호 작용에 대해서는 다른 테스트를 수행해야합니다.

— 마크 프리드먼
소스

"실제 UI와 UI 상호 작용에 대해 다른 테스트를 수행해야합니다." 이것이 바로 제 질문입니다. 왜 UI 테스트가 갑자기 '다른 테스트'(즉, 통합 테스트)의 일부가됩니까? 나는 스티브 샌더슨의 내용을 많이 보았고 이것이 내가이 길을 시작하게 한 것입니다. 기본적으로 그가 'MvcFakes'프로젝트로하고있는 일을 복제하고 이전 MVC 릴리스 용으로 작성된 코드 문제에 부딪 히려고했습니다. .

— 피터 Bernier은

1

다음 URL을 확인하여 컨트롤러 작업에 의해 반환 된 View를 테스트하는 방법, 컨트롤러 작업에 의해 반환 된 View Data를 테스트하는 방법 및 하나의 컨트롤러 작업이 두 번째 컨트롤러 작업으로 리디렉션되는지 여부를 테스트하는 방법을 배울 수 있습니다. 이 짧은 기사에서 MVC에서 뷰 데이터 테스트에 대해 설명 합니다.

— 자이 피
소스