Porady dotyczące testowania jednostek - jak przetestować urządzenie .asmx

Question

Właśnie skończyłem tworzenie usługi internetowej, która będzie używana przez niestandardowy wewnętrzny system .NET. Chciałbym uzyskać porady na temat najlepszego sposobu ustawienia klas testowych i metod przez .asmx (najlepsze praktyki, jak przetestować połączenia, czego nie robić itp.) W szczególności w środowisku .NET 3.5.

Będę używał NUnit do wykonania tego testu. Czy jest to tak proste, jak tworzenie projektu testowego, dodawanie do niego usługi, a następnie tworzenie klasy testowej i instancji tej usługi. Następnie zacznij tworzyć swoje metody testowania?

Potrzebuję przetestować zarówno metody .asmx, jak i .asmx.cs (jednostka przetestuj metody), aby wiedzieć, czy przekazuję to członkowi zespołu, że zadziała.

Może to nie jest możliwe, aby przetestować .asmx.cs bezpośrednio, a ja po prostu muszę przetestować za pomocą testów integracyjnych. Sądzę, że to, czego naprawdę potrzebowałbym, to kpić z mojego .asmx. Prawdopodobnie nie jest to możliwe.

Answer 1

Najlepszą praktyką testu jednostkowego nie jest testowanie pliku ASMX, ale części (jednostki) za plikiem ASMX za. Jeśli możesz podzielić swój kod na małe i oddzielne części, możesz przetestować jednostki.

Jeśli chcesz przetestować sam plik ASMX, mówisz o teście integracji. Możesz użyć NUnit do tego w opisany sposób, ale to nie jest testowanie jednostkowe.

Answer 2

Jak stwierdził Lodewijk, najlepiej jest nie testować pliku ASMX. Zamiast tego wyodrębnij logikę z tego pliku do plików klas, które obsługują zachowanie, którego szukasz. W ten sposób możesz przetestować te jednostki w izolacji od interfejsu użytkownika. Może się okazać, że prawdziwy problem polega na tym, że w warstwie interfejsu użytkownika jest zbyt wiele logiki biznesowej.

Jeśli chcesz przetestować sam plik ASMX, powinieneś rozważyć testowanie ręczne, testy integracyjne lub testy akceptacyjne ... ale jeśli możesz przenieść swoją logikę do warstwy biznesowej, prawdopodobnie znajdziesz ją dużo łatwiej przetestować.

Answer 3

Niestety jest to problem związany z usługami internetowymi .asmx, są one zależne od ASP.net, najlepszym rozwiązaniem byłoby utrzymywanie usługi internetowej .asmx jako kodu pośredniczącego i wyodrębnienie logiki usługi sieciowej do czystej zależności - zamiast tego testuj bez użycia klasy i jednostki. Inną alternatywą jest uruchomienie testów integracji.

W dłuższej perspektywie, jeśli testowanie urządzenia jest dla Ciebie ważne, lepiej być przygotowanym przy użyciu urządzenia web service framework, które zostało zaprojektowane z testowaniem urządzenia od samego początku.

Answer 4

Możliwe, że nie rozumiesz, o czym mówią inni. Plik .asmx powinien mieć brak logiki wartej przetestowania. Jeśli naprawdę jest tylko opakowaniem połączeń biznesowych, to nic nie dodaje i nie trzeba go testować. Jeśli coś doda, wyodrębnij, dopóki plik .asmx nie będzie zawierał nic innego, jak tylko wywołanie tranzytowe.

Co zawiera plik .asmx, który nie może zostać wyodrębniony na osobne, sprawdzalne klasy?