Tworzenie testu za pomocą parametru url, który wstawia wartości do formularza

Question

Ponieważ jestem dość nowy w tworzeniu aplikacji internetowych mam obecnie pewne trudności w implementacji niektórych funkcji testowania.

W ramach projektu Obecnie pracuję (An MVC 3 Web App do przetwarzania płatności) Zostałem poproszony o utworzenie TESTMODE które mogą być dostępne za pośrednictwem adresu URL w ten sposób:

http://websiteurl?testmode=1 

Ideą tego jest to, że gdy jeden z zespołów programistycznych dodaje parametr testmode do adresu URL, zestaw wartości formularza jest generowany automatycznie w celu zaoszczędzenia czasu na wprowadzanie danych za każdym razem, gdy testowana jest aplikacja.

Obecnie mam if w kontrolerze, który wykorzystuje Request.QueryString ustawić parametr jest poniżej kod, który Obecnie używam:

if (Request.QueryString.AllKey.Contains("tm")) 
{ 
    if (Request.QueryString["tm"] == 1) 
    { 
     insert values to be generated 
    } 
} 

Biorąc pod uwagę kontekst, co jeśli byłaby najlepsza metoda osiągnięcia tego?

byłoby możliwe za pomocą ramy szyderczy takich jak Min lub RhinoMocks stworzyć fałszywe repozytorium zamiast pobierania wyników z bazy danych lub lepiej byłoby mieć dane testowe wstępnie załadowane w bazie danych?

Answer 1

Zacznę od enkapsulacji testu "TestMode".

Chciałbym stworzyć podstawowy kontroler i dodać następującą właściwość:

// I would consider retrieving this from web.config 
protected string testModeKey = "tm"; 

public bool IsTestContext 
{ 
    get 
    { 
     return Request.QueryString[testModeKey] != null; 
    } 
} 

Alternatywnie, należy rozważyć pisanie metodę rozszerzenia dla HttpRequest:

public static bool IsTestContext(this HttpRequest request, string testModeKey = "tm") 
{ 
    request.QueryString[testModeKey] != null; 
} 

To jest na uboczu. Zastanówmy się, w jaki sposób możemy wstawić wartości. Podejmuję tutaj kilka założeń, ale byłbym zainteresowany testowaniem jednostki kontrolera.

Zakładam, że Twoje dane są zwracane z niektórych IDataRepository i masz dwie implementacje repozytorium: FakeDataRepository i ReadDataRepository.

Następnie można napisać fabrykę lub proste polecenie ifelse, aby zdecydować, którego repozytorium użyć.

IDataRepository DataRepository { get; set; } 

if (Request.IsTestContext) 
    DataRepository = new FakeDataRepository(); 
else 
    DataRepository = new RealDataRepository(); 

Będzie to działało zgodnie z oczekiwaniami, ale moim zdaniem nie jest dobrym rozwiązaniem. Przyjrzałbym się testowaniu jednostek kontrolerów. Czy możesz podać więcej szczegółów na temat tego, co chciałbyś przetestować, ponieważ przedstawiam tutaj kilka założeń i przypuszczeń?

Answer 2

tak, że masz kilka szczegółów na temat, jak aplikacja jest obecnie rozplanowane mam pod warunkiem, szczegóły poniżej:

Podstawowa struktura aplikacji szablonowi jedwabną projekt uszkodzi aplikację do logiki biznesowej, Danych Poziom, prezentacja i testy jednostkowe, kontroler, w którym implementuję ten tryb testowy, już dziedziczy z podstawowego kontrolera, który obecnie zawiera implementację wzorca Microsoft.Practices.ServiceLocation.

lokalizator usług dostęp do czterech usług znalezionych w projekcie Domena domeny logicznej, trzy z tych repozytoriów dostępu, które zawierają wartości dla trzech list rozwijanych, czwarty dostęp do realizacji usługi transakcji dla rozwiązania płatniczego (SagePay), który został zintegrowany z aplikacją używa SagePayMvc.dll.

Wszystkie repozytoria dziedziczą z repozytorium bazowego Mam obecnie sześć repozytoriów, które dziedziczą z tej bazy, trzy znów są przeznaczone do zapełniania list rozwijanych, pozostałe trzy informacje o sklepach dla studentów, posiadaczy kart i szczegółów zamówienia, tryb testowy w zasadzie uzyskuje dostęp Repozytorium dla studentów, które ma obecnie wypełnić formularz ze szczegółowymi danymi studenta, obecnie dane posiadacza karty można wypełnić za pomocą JQuery.

Istnieją dwa zestawy modeli jeden zestaw w Business Logic i drugi w warstwie danych, z walidacji modelu jest zdefiniowana w Domenie Business Logic.

Model widoku, za pośrednictwem którego uzyskuję dostęp do modeli, obecnie korzysta z modelu domeny.

W celu utworzenia repozytoriów używam Entity Framework Code First approach, obecnie tworzy repozytoria jako bazę danych, w której tabele odpowiadają każdemu ze zdefiniowanych modeli.

Celem tego trybu testowego jest szybkie wypełnienie nie unikatowych pól formularza (obecnie mam zaimplementowaną pewną logikę, która uniemożliwi Uczniom wprowadzanie już istniejącej nazwy), tak aby inni członkowie zespołu korzystali z aplikacji mogą szybko ocenić, czy aplikacja działa, szczególnie w przypadku zespołu projektantów, którzy stosują stylizację do aplikacji.

Mam obecnie jedną konfigurację klasy testowej, która testuje twierdzenie, że repozytorium studentów może utworzyć nowego ucznia, dane, które tu zdefiniowałem, uzyskują dostęp do fałszywego repozytorium zdefiniowanego przy pomocy Moq.