"Szybka" integracja Testowanie usług WCF

Question

Kontekst

Jestem wielkim fanem tego, co Roy Osherove nazywa "testowaniem szybkiej integracji". To jest test integracyjny, który:

• Jest wykonywany wyłącznie na twoim pudełku programistycznym. Nie ma potrzeby oddzielnego środowiska.
• Pomimo testowania integracyjnego, testy takie są zwykle uruchamiane z narzędzia do testowania urządzenia (NUnit, MsTest itp.).
• Zwykle uruchamia się w pamięci: pojedynczy proces jest wykonywany.
• Działa szybko. Nie powinno być wdrożenie sekund-długie następnie sekund-długie startu spinania itp
• Musi być przyjazny kontrola źródło:
  • Inni deweloperzy powinni być w stanie po prostu pociągnąć za źródło i uruchomić szybkich testów integracyjnych bez problemów z konfiguracją (np. konfigurowanie katalogów wirtualnych IIS itp.)
  • Zawsze, gdy jest to możliwe, powinien być zgodny z automatycznymi testami ciągłej integracji (CI).

Problem

Biorąc pod uwagę VS 2010 rozwiązanie z kilku usług WCF być badane integracja, byłem badania jak najlepiej udać się na ten temat. Moje dalsze wymagania dotyczące konfiguracji testu to:

• Usługi WCF są zagnieżdżane. Oznacza to, że jedna usługa może wywołać inną podczas testu szybkiej integracji.
• Stos WCF musi być w pełni lub w większości sprawny.
  • Bezpośrednie wywoływanie punktu wejścia do umowy serwisowej może być ok dla testów jednostkowych, ale nie dla tej formy testowania integracji.
  • Powiązania REST i BasicHttp powinny działać, a najlepiej również wsHttpBinding.
• Web.config
  • web.config transformacji (XDT) każdego projektu WCF powinna być sprawna, chociaż rozmieszczenie mogą lub nie mogą występować, aby osiągnąć ten test.
  • Narzędzie do testowania urządzenia, takie jak MsTest lub NUnit, powinno być , a nie wymagać skonsolidowanego pliku web.config, który reprezentuje wszystkie usługi hostowane podczas testu.
• Hosting usług WCF może być 32-bitowy lub 64-bitowy.
• Usługa hostingu WCF może być albo w pamięci za pomocą narzędzia testowego jednostkowej lub out-of-process przez takich gospodarzy jak Cassini, IIS Express, itp
  • Jestem zdecydowanie przechyla się w kierunku wlotami podejście do pamięci, ponieważ upraszcza problemy z synchronizacją testów. Innymi słowy, niektóre z moich usług WCF działają asynchronicznie i są zakończone po odpowiedź WCF została już wysłana do urządzenia tekstowego.Dzięki podejściu w pamięci mogę wykonać test urządzenia Monitor.Wait, aby upewnić się, że praca asynchroniczna została ukończona przed zakończeniem testu. W przypadku wieloprocesowego hostingu i testowania prawdopodobnie muszę polegać na systemie plików i zdarzeniach w systemie plików, aby osiągnąć tę samą synchronizację.

Odpowiedź?

Chciałbym wymienić moje dotychczasowe wyniki i zapytać, jakich narzędzi lub technik brakuje mi. Ponownie, to pytanie dotyczy Visual Studio 2010, chociaż mile widziane są dodatkowe komentarze na temat 2012 roku.

W przypadku rozwiązań in-memory wydaje się, że istnieją dwie podstawowe opcje. Użyj jednej instancji z jednej usługi dla każdej usługi lub użyj jednego z variety of other self-hosting tools. W tym drugim linku pierwotne pytanie dotyczyło hostingu produkcji - ale większość wymienionych narzędzi jest zdolnych do hostingu w trybie self lub in-memory.

Autor CassiniDev, wymieniony w drugim linku powyżej, zasugerował, że CassiniDev jest używany, gdy testowanie pętli zwrotnej (localhost) nie jest wystarczające. W moim przypadku podejrzewam, że testowanie pętli zwrotnej jest w porządku. Autor sugeruje, że gdy testowanie pętli zwrotnej jest w porządku, bardziej lekką opowieścią jest użycie jego WebDevServer code. Jeśli dobrze rozumiem, kod WebDevServer jest w rzeczywistości wewnętrznym kodem Visual Studio, który odzwierciedlił i zmodyfikował w celach testowych.

W przypadku rozwiązań on-box (wieloprocesowych) widzę, że istnieje sposób na zrobienie Cassini fit the 64 bit requirement. W przeciwnym razie, w przypadku usług IIS Express lub IIS, nie mam pewności co do problemów konfiguracyjnych programisty. Zwykle, gdy programista konfiguruje IIS Express lub IIS na konkretnym komputerze, zwykle pozostali programiści pozostają bez tych informacji konfiguracyjnych i starają się, aby test działał na ich własnym komputerze. Widziałem, jak programiści tworzą skrypty, które używają appcmd.exe do zautomatyzowania takiej konfiguracji, ale zbyt często takie skrypty są słabo utrzymywane. Chcę spróbować uniknąć tego scenariusza.

W obu scenariuszach wierzę, że moja opcja (opcje) dla automating the web.config transform (XDT), without a deploy, is discussed here.

Ok, jakie są lepsze strategie i taktyki? Chciałbym wiedzieć ...

Answer 1

Nie odpowiada to na pytanie o test szybkiej integracji, o który prosił pytający, ale poniższy link jest najbardziej wyczerpującym przewodnikiem na temat testowania WCF.

https://codereview.stackexchange.com/questions/33379/make-wcf-service-testable?newreg=016e2809b68248958ff3c45973efe643

Jednak nie mogę ręczyć za ile ten przewodnik zabierze Cię w zakresie rozwijania testy dla pełnej funkcjonalności stosu WCF.