Testowanie aplikacji WPF z testami CodedUI, czy zakodowany projekt testowy ui ma wspólne rozwiązanie?
Najpierw jakiś kontekst; opracowujemy dużą aplikację WPF na komputery stacjonarne w .NET 4.5 z 64-bitowym systemem Windows 7 i 8. Korzystamy z Visual Studio 2012.2 (wkrótce będzie to 0,3, a prawdopodobnie 2013!) i TFS 2012 (ponownie .2 wkrótce będzie to .3 to 2013).
Obecnie ten produkt znajduje się w jednym dużym rozwiązaniu (nieco ponad 50 projektów), który generuje exe WPF, ładuje biblioteki DLL i ładnie instaluje MSI.
Używamy TFS (bramkowanego i zaplanowanego) do zbudowania rozwiązania, jego instalatora (WiX) i uruchomienia testów (SpecFlow dla testów jednostkowych BDD i MSTest) i to działa bardzo dobrze.
Mam osobną zaplanowaną kompilację TFS, która wdraża MSI do fizycznego stanowiska testowego w niezaufanej domenie AD za pomocą skryptu PowerShellTFS2012 Skrypty wdrażania szablonu LabDefault.11 nie działają, „Team Foundation Server nie mógł ukończyć zadania wdrażania” po szczegóły wyzwań związanych z tym!)
OK, więc tam jestem, chcę teraz przejść do następnego kroku; Testy CodedUI do przeprowadzenia pełnego testu integracji aplikacji; Chcę „Smoke Test” moich kompilacji.
Więc będąc prostą duszą, dodałem nowy projekt do mojego rozwiązania produktów; projekt testowy CodedUI.
To z radością uruchamia lokalnie zainstalowany produkt (a nie tylko wbudowany produkt, ponieważ ostatecznie chcę, aby CUIT działał na wdrożonej platformie testowej jako test dymu, a ta platforma zainstalowała właśnie MSI, który właśnie zbudowałem) i wykonuje pewne UI testy z twierdzeniami.
Terazmoim problemem jest projekt CUIT jako część rozwiązania produktów, które lokalny test uruchamia i uruchamia moje testy CUIT, a to jest niepożądane. Chcę tylko przeprowadzić testy CUIT w fazie testów kompilacji laboratorium.
Więcwprowadzanie projektu CUIT do rozwiązania produktu to zły pomysł? lubczy powinno to być oddzielne rozwiązanie? Dzielenie ich wydaje się niewłaściwe, ponieważ są ze sobą powiązane; projekt CUIT jest testem integracji pełnego stosu dla aplikacji wdrażanej przez rozwiązanie.
Czy mogę dołączyć CUIT do rozwiązania produktów i powstrzymać testera od obejrzenia testów? czy lepiej jest mieć tylko dwa rozwiązania?
Jakie są zalety i wady ludzi?
AktualizacjaW końcu stworzyliśmy nowe rozwiązanie zawierające zakodowany projekt testowy interfejsu użytkownika i upewniliśmy się, że został zbudowany przy użyciu tej samej kompilacji TFS, która zbudowała rozwiązanie interfejsu użytkownika. To pozwala nam ładować i uruchamiać kodowane testy interfejsu użytkownika lokalnie bez problemów, testy jednostkowe w głównym projekcie interfejsu użytkownika pozostają niezakłócone. Nadal wydaje się trochę chaotyczny, ale w zespole wieloosobowym na użytkownika ustawienia testu były zbyt niewygodne, dzieląc kodowany interfejs użytkownika na inne rozwiązanie, które było prostsze.