ASP.NET - Jak testujesz WebControls w jednostce?

Question

W porządku.

Tak więc sądzę, że najwyższy czas, aby przejść do testów jednostkowych, ponieważ wszyscy zaczęli o tym mówić wystarczająco długo. Zainstalowałem NUnit i przeszedłem kilka tutoriali typu "wprowadzenie do testów jednostkowych".

Obecnie tworzę niewielki framework, aby pomóc w przebudowie jednej z naszych aplikacji internetowych, dlatego stworzyłem projekt VS2008 dla mojej architektury i chcę go przetestować w miarę możliwości.

Jak u licha chodzi o testowanie urządzenia WebControls? Wszystkie metody są chronione lub prywatne, a ponieważ jest to framework, nie ma nic innego jak WebControls.

Jakieś wskazówki?

Burns

Answer 1

Możliwe jest tworzenie architektur typu model-widok-kontroler lub model-widok-prezenter bez użycia pełnego schematu. Przekonałeś się już, że testowanie jednostkowe komponentów ui jest trudne. Są na to różne sposoby, ale prawdopodobnie nie chcesz iść tą drogą. Zwykle sprawi to, że twoje testy będą bardzo trudne do utrzymania, więcej koszmarów związanych z utrzymaniem jest czymś, co programiści mogą zrobić bez :-)

Spróbuj oddzielić funkcjonalność, którą chcesz przetestować w klasie "kontroler" lub "prezenter". Następnie przetestuj tę klasę. Aby uczynić go bardziej testowalnym, możesz ukryć klasę usercontrol (widok) za interfejsem i sprawić, że kontroler lub prezenter będzie rozmawiał z widokiem przez interfejs. W ten sposób możesz wykopać widok w swoich testach.

Wiem, że to brzmi jak dużo pracy i wygląda na obejście problemu, ale jeśli się przyzwyczaicie, jest to naprawdę ładna architektura, która znacznie ułatwia zmianę zachowania interfejsu użytkownika. Zawsze możesz zacząć używać "prawdziwego" środowiska mvc, kiedy naprawdę tego potrzebujesz :-)

Answer 2

Ues atrybutu assembly:InternalsVisibleTo i będziesz mieć dostęp do tych prywatnych członków.

Umieścić go w swoim projekcie WebControl za AssemblyInfo.cs (pod Properties Node)

[assembly:InternalsVisibleTo("YourTestProjectName")] 

Answer 3

znaleziony największy punkt bólu z ASP.NET. Jeśli chodzi o zamknięte, prywatne klasy, które utrudniają testowanie jednostkowe.

Jest to główny powód, dla którego użytkownicy TDD będą używać szkieletu MVC (ASP.NET MVC, Castle MonoRail), ponieważ zapewnia on wyraźne oddzielenie od szablonów widoku i logiki kontrolera. Kontrolery są w pełni testowalne.

Answer 4

Wspomniany wyżej framework MVC to najlepszy sposób na sprawdzenie działania kontrolki. Jednak testowanie jego działania jest nieco inne.

Jest to całkowicie wyłączone z mankietu, ale można spowodować, że kontrola użytkownika ujawni niektóre chronione metody i właściwości w celu zwrócenia informacji o sprawdzeniu poprawności, a następnie sprawdzi je kontrolująca użytkownik. Ta kontrola może wypełniać pola, naciskać przyciski, a co nie. Trochę niechlujny, ale może działać.

Answer 5

Możesz również rzucić okiem na ten framework Rhino Igloo. Jest to skompromitowane środowisko MVC dla WebForms.

Answer 6

This to już dawny artykuł, ale używałem NUnitASP do pisania testów pod kątem asp.net WebControls w 2004 roku.W tym artykule podano szczegółowy przykład testowania prostej kontroli za pomocą ich koncepcji tworzenia odpowiedniej klasy "Tester", która zawiera szczegóły kontroli nad tobą. Tester może (powinien) również być w tym samym zespole, co kontrola, więc może dzielić pewne rzeczy między nimi (np. Funkcje użytkowe, stałe itp.).

Do tej pory użyłem techniki (i innych wykorzystuję warianty techniki) do przetestowania bardzo wyrafinowanych kontroli.

Mam nadzieję, że to jest pomocne.

Answer 7

Ivonna może testować WebControls w izolacji, w ramach Asp.Net Wystarczy zadzwonić session.GetControl („Path.ascx”) i sprawdzić, czy posiada wszystkie niezbędne właściwości.

Answer 8

Można również sprawdzić komponenty testowe za pomocą przeglądarki, ponieważ użytkownik zobaczyłby je za pomocą architektury testowej, takiej jak WebAii. Widziałem, jak to działa i jest całkiem fajne. Powiedziano mi też, że możesz podłączyć go do zautomatyzowanych buildów, ale nie widziałem tego od teraz.

Nadzieja to pomaga ...

Answer 9

przetestować je tak:

[Test] 
public void ConditionQueryBuilderTest_RendersProperHtml() 
{ 
    var sw = new StringWriter(); 
    var queryBuilder = new ConditionQueryBuilderStub 
    { 
     ID = "UnitTestbuilder", 
     QueryBuilderURL = @"\SomeAspxPage\SomeWebMethod", 
     ResetQueryBuilderURL = @"\SomeAspxPage\OnQueryBuilderReset", 
     FilterValuesCollection = new Dictionary<int, string> { {15, "Some Condition"}} 
    }; 
    queryBuilder.RenderAllContents(new HtmlTextWriter(sw)); 

    AppendLog(sw.ToString()); 

    Assert.AreEqual(ExpectedHtml, sw.ToString()); // ExpectedHTML is the raw expected HTML 
} 

Oto moja en:

internal class ConditionQueryBuilderStub : ConditionQueryBuilder // ConditionQueryBuilder is a WebControl 
{ 
    internal void RenderAllContents(HtmlTextWriter writer) 
    { 
     RenderContents(writer); 
    } 
}