ASP.NET MVC로 테스트 중심 개발 - 어디서부터 시작해야합니까?

Question

저는 TDD (Test-Driven Development)에 대해 많이 읽었으며 개인적인 경험을 바탕으로 매우 강렬한 원칙을 발견했습니다.

지금 제가 시작한 프로젝트를위한 웹 사이트를 개발 중이며 TDD를 실천에 옮기고 싶습니다.

그래서 ... Visual Studio 2010에서 빈 솔루션을 만들고 ASP.NET MVC 웹 사이트 프로젝트와 테스트 프로젝트를 추가합니다.

내 도메인 개체에 대해 '도메인'이라는 클래스 라이브러리와이를위한 테스트 프로젝트를 추가합니다.

이제 어디서부터 시작해야할지 궁금합니다. 내가 옳은 일을하기 전에 시험을 치러야할까요? 질문은 - 도메인 객체에 대한 테스트를 작성해야합니까? 그렇다면 도메인 객체가 아직 존재하지 않기 때문에 정확히 무엇을 테스트해야합니까?

아니면 웹 사이트 프로젝트로 시작하고 테스트를 작성해야합니까? 그렇다면 무엇을 테스트해야합니까? 홈 컨트롤러/색인 작업?

Answer 1

일반적으로 개발할 응용 프로그램에 대한 일련의 이야기를 수집하는 것으로 시작합니다. 그로부터 나는 일반적으로 "종이"에 도메인 모델을 생성합니다. 구현할 이야기를 구성하고 첫 번째 이야기 집합의 DB에 도메인 모델을 만들기 시작합니다.

초기 DB가 생기면 ORM을 사용하여 SQL에 대한 LINQ를 사용하여 DB 테이블을 초기 클래스 집합에 매핑합니다. 나는 일반적으로 단위 테스트 생성 코드를 작성하지 않기 때문에 시작하기에 충분한 양의 코드를 제공합니다. 그런 다음 첫 번째 도메인 클래스의 기능을 구현하기 위해 구현되지 않은 예외를 throw하는 스텁 메서드를 만듭니다. 일반적으로 유효성 검사 논리부터 시작합니다. 스텁 메소드가 있으면 VS 마우스 오른쪽 버튼 메뉴를 사용하여 해당 메소드에 대한 하나 이상의 단위 테스트를 만들 수 있습니다. 그럼 너는 네 길을 갈거야.

일단 첫 번째 이야기의 도메인 개체를 완성하면 MVC 측면에 대한 작업을 시작합니다. 먼저, 첫 번째 뷰에 대한 뷰 모델을 생성합니다. 이들은 일반적으로이 시점에서 빈 컨테이너 클래스입니다. 그런 다음 뷰를 만들고 뷰 모델에 강력하게 입력합니다. 뷰에서 필요에 따라 뷰 모델에 속성을 추가하여 뷰를 완성 해 보겠습니다. 뷰 모델은 단순히 컨테이너 일뿐 일반적으로 연관된 단위 테스트는 없습니다. 그러나 후속 컨트롤러 테스트에 사용됩니다.

일단 뷰가 완료되면 (또는 적어도 초기 개념이 완료되면) 스텁 컨트롤러 액션이나 액션을 만들고 다시 스텁 메서드가 구현되지 않은 예외를 throw합니다. 컴파일하기에 충분하고 도구를 사용하여 단위 테스트를 만들 수 있습니다. 필자는 방법을 테스트하고 주어진 입력에 적절하게 작용하고 적절한 뷰 모델을 생성하는 데 필요한대로 진행합니다. 이 메소드가 여러 개의보기 모델을 생성 할 수있는 경우 (예 : 여러 개의보기를 렌더링하는 경우) 스토리 또는 스토리가 완료 될 때까지 뷰 모델/뷰/컨트롤러 코드를 만드는 과정을 반복 할 수 있습니다.

스토리 집합이 구현 될 때까지 필요한만큼 반복하여 길을 따라 리팩터링하십시오.

Answer 2

당신은 테스트중인 클래스는 C#을 같은 정적 언어로 조금 극단적 인 것 같다 선언하기 전에 ASP.NET MVC 1.0 Test Driven Development

Answer 3

유닛 테스트를 작성 볼 수 있습니다. 따라서 도메인 클래스를 선언하고, 이러한 도메인 객체에서 수행 할 연산을 정의하는 몇 개의 인터페이스를 내 보낸 다음 인터페이스를 구현할 클래스를 추가하고 메소드를 그대로 두어 NotImplementedException을 던집니다. 그 순간 모든 타입이 알려져 있기 때문에이 클래스에 대한 단위 테스트를 작성할 수 있습니다. 실패 할 테스트를 실행 한 다음 메서드를 구현하고 테스트를 다시 실행하면 성공합니다. 그런 다음 구현을 리팩토링하고 최적화 할 수 있으며 단위 테스트는 계속 통과해야합니다.

좋은 도메인 모델과 데이터 액세스 레이어를 만들었 으면 이전에 정의한 인터페이스를 사용하여 컨트롤러를 만드는 웹 프로젝트로 이동할 수 있습니다 (이 인터페이스를 사용하는 생성자를 만들어서). 컨트롤러를 데이터 액세스 코드와 별도로 테스트 할 수 있도록 인터페이스를 mock 객체로 바꾸어 컨트롤러에 대한 단위 테스트를 작성합니다.

가장 중요한 것은 : 클래스와 인터페이스를 추가하는 것을 두려워하지 마십시오. 나는 사람들이 동시에 여러 가지를 수행하고 테스트하기 어려운 거대한 방법을 쓰는 것을 보았다. 가능한 다른 입력에 대해 예상되는 출력은 다음과 같은 스펙을 쉽게 작성할 수있는 메소드로 다른 태스크를 분리하십시오.

Answer 4

길게 대답하려면 다음과 같이 약간의 조치를 취해야합니다. 테스트를 통과하는 가장 간단한 코드를 작성 -

1) 실패한 테스트

[Test] 
    public void AddSameTag() 
    { 
     UserMovie userMovie = new UserMovie(); 

     userMovie.AddTag("action", "dts", "dts"); 
     Assert.AreEqual(2, userMovie.Tags.Count); 
    } 

에게 2) - 첫 물품.

public virtual void AddTag(params string[] tags) 
    { 
     foreach (var text in tags) 
     { 
      Tag tag =new Tag(text.Trim()); 
      if (!movieTags.Contains(tag)) 
       movieTags.Add(tag); 
     } 
    } 

3) - 팩터

. ASP.NET MVC 및 TDD 스타터의 경우 Controller Test를 무시하고 TDD별로 도메인에 집중할 수 있습니다.