Rozwój oparty na testach z ASP.NET MVC - od czego zacząć?

Question

Czytałem dużo o rozwoju opartym na testach (TDD) i uważam, że zasady są bardzo atrakcyjne, oparte na osobistych doświadczeniach.

W tej chwili pracuję nad stroną internetową poświęconą projektowi, w który jestem zaangażowany, i chciałbym spróbować swoich sił w praktycznym wdrażaniu TDD.

Więc ... Tworzę puste rozwiązanie w Visual Studio 2010, dodam projekt strony ASP.NET MVC i projekt testowy.

Dodaję także bibliotekę klas o nazwie "Domena" dla moich obiektów domenowych i projekt testowy do tego.

Teraz zastanawiam się, od czego zacząć. Czy powinienem napisać test, zanim zrobię cokolwiek w porządku? Pytanie brzmi - czy powinienem zacząć pisać testy dla obiektów domeny? Jeśli tak, to na co dokładnie powinienem przetestować, ponieważ obiekty domeny jeszcze nie istnieją?

Czy powinienem zaczynać od projektu strony internetowej i pisać testy na to? Jeśli tak, na co mam napisać test? Działanie kontrolera domowego/indeksowania?

Answer 1

Zwykle zaczynam od zebrania zestawu historii do aplikacji, którą zamierzam rozwinąć. Z tego generuję model domeny, zwykle na "papierze". Organizuję historie, które zamierzam wprowadzić i rozpocząć tworzenie modelu domeny w bazie danych dla pierwszego zestawu opowiadań.

Gdy mam początkowy DB, używam ORM, w moim przypadku LINQ do SQL, aby odwzorować tabele DB na zestaw klas początkowych. Zazwyczaj nie generuję kodu generowanego przez test, więc daje mi to sporo kodu jako podstawy do rozpoczęcia. Następnie utworzę metodę pośredniczącą, która zgłasza niezaimplementowany wyjątek, aby zaimplementować jedną cechę pierwszej klasy domeny, z którą pracuję. Zazwyczaj zaczynam od logiki sprawdzania poprawności. Po uzyskaniu metody pośredniczącej można użyć menu prawego przycisku myszy, aby utworzyć jeden lub więcej testów jednostkowych dla tej metody. Jesteś na dobrej drodze.

Po ukończeniu obiektów domeny dla pierwszej historii, zacznę pracować z aspektami MVC. Najpierw utworzę modele widoku dla pierwszego widoku. Zwykle są to po prostu puste klasy kontenerów. Następnie utworzę widok i mocno wpiszę go do modelu widoku. Zacznę od widoku, dodając właściwości do modelu widoku zgodnie z potrzebami widoku. Zwróć uwagę, że ponieważ model widoku jest po prostu kontenerem, zwykle nie są związane z nim testy jednostkowe. Zostanie jednak użyty w kolejnych testach kontrolerów.

Po zakończeniu widoku (lub przynajmniej mój wstępny koncept jest kompletny), następnie utworzę dla niego akcję kontrolera skrótów lub działania, ponownie metoda pośrednicząca po prostu zgłasza wyjątek niezaimplementowany. To wystarcza, aby skompilować i pozwolić mi używać narzędzi do tworzenia testów jednostkowych. Postępuję w razie potrzeby, aby przetestować metodę (metody) i upewnić się, że działa ona odpowiednio na dane dane wejściowe i tworzy odpowiedni model widoku. Jeśli metoda może generować wiele modeli widoku, tzn. Renderować wiele widoków, mogę iterować nad procesem tworzenia widoku modeli/widoków/kodu kontrolera do czasu ukończenia historii lub historii.

Powtarzaj tę czynność, dopóki nie zostanie wprowadzony zestaw historii, a następnie zreorganizuj.

Answer 2

Możesz zajrzeć ASP.NET MVC 1.0 Test Driven Development

Answer 3

pisanie testów jednostkowych przed nawet deklarowania klasa testujesz wydaje się nieco skrajny w statycznym językach takich jak C#. Zacznij od deklaracji klas domeny, wyrzuć kilka interfejsów definiujących operacje, które będziesz wykonywać na tych obiektach domeny, a następnie dodaj klasę, która zaimplementuje interfejs, pozostawiając metody tylko rzucając NotImplementedException. W tym momencie możesz napisać test jednostkowy dla tej klasy, ponieważ wszystkie typy są znane. Uruchomiłeś test, który się nie powiedzie, a następnie zaimplementujesz metodę i ponownie uruchomisz test - przejdzie. Wtedy możesz refaktoryzować i zoptymalizować swoją implementację, twój test jednostek powinien jeszcze przejść.

Po uzyskaniu ładnego modelu domeny i warstwy dostępu do danych można przejść do projektu internetowego, w którym tworzone są kontrolery, za pomocą zdefiniowanych wcześniej interfejsów (tworząc konstruktor, który obsługuje ten interfejs). Piszemy test jednostkowy dla tego kontrolera, zastępując interfejs próbnym obiektem, aby można było testować działania kontrolera w oderwaniu od kodu dostępu do danych.

Co najważniejsze: nie bój się dodawać klas i interfejsów. Widziałem ludzi piszących ogromne metody, które wykonują wiele rzeczy jednocześnie i które są trudne do przetestowania. Spróbuj wyodrębnić różne zadania w metody, które można łatwo napisać specyfikacje: jaki wynik wyjściowy dla różnych możliwych wejść.

Answer 4

Aby uzyskać długą odpowiedź, należy wykonać małe kroki w ten sposób.

1) -First napisać upadającego test

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

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

2) - najprostszy napisać kod, aby zdać test.

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) - Refactor

. W przypadku startera ASP.NET MVC i TDD można zignorować test kontrolera i skoncentrować się na domenie za pomocą TDD.