Jak mogę napisać automatyczny test jednostkowy GUI w Xcode?

Question

Chcę napisać test jednostkowy tylko GUI część mojej aplikacji Cocoa.

W teście jednostek podręcznych istnieje szkielet testowy i przypadek testowy, który wywołuje testowaną jednostkę. Cały kod poniżej tej jednostki jest wyszydzany. Tak więc zarówno wejście, jak i wyjście są kontrolowane i monitorowane; testowany jest tylko kod w testowanej jednostce.

Chcę zrobić to samo, gdy testowana jednostka jest moim GUI:
1) Skonfigurować pewien rodzaj framework, w którym mogę napisać kod, który będzie manipulować i kontrolować elementy sterujące GUI.
2) Połącz moje kontrolki GUI z makrami mojego rzeczywistego kodu, a nie z rzeczywistymi instancjami.
3) Uruchom test, który manipuluje elementami sterującymi, a następnie sprawdza próbny obiekt, aby sprawdzić, czy poprawne metody zostały wywołane z poprawnymi parametrami i sprawdza GUI, czy odpowiedzi z obiektu próbnego powodują poprawne zmiany w widżetach. .

Ktoś to robi? Jeśli tak to jak? Jakieś pomysły na to, w jaki sposób mogę to zrobić?

Dzięki,

Pat

(Edit), otrzymując bardzo konkretny przykład, chcę:
1) Napisz przypadek testowy, który będzie wybrać pozycję menu 'MyMenu' -> „MyItem ". W tym przypadku testowym chcę sprawdzić, czy metoda [AppDelegate doMyItem] jest wywoływana dokładnie raz i że nie są wywoływane żadne inne metody w AppDelegate.
2) Wygeneruj próbny obiekt AppDelegate. (Wiem, jak to zrobić)
3) W jakiś sposób (handwaving tutaj) łączę moją aplikację, tak, że w miejsce prawdziwej instancji dołącza się fałszywa instancja AppDelegate.
4) Uruchom test. Zobacz, jak to się nie uda, ponieważ 1) Nie utworzyłem jeszcze MyMenu. 2) Nie stworzyłem jeszcze MyItem. 3) Nie zrobiłem IP pracy, aby połączyć MyItem z [AppDelegate doMyItem] lub 4), ponieważ nie napisałem jeszcze metody "doMyItem".
5) Napraw powyższe cztery problemy (po jednym na raz, jeśli czuję się naprawdę pedantycznie tego dnia).
6) Ponownie uruchom test i obejrzyj go.

Czy to sprawia, że ​​pytanie jest jasne?

Answer 1

Oto kilka popularnych sposobów robienia tego w ogóle (powinno działać z większością, jeśli nie wszystkimi językami kompatybilnymi z kakao).

1 - utwórz interfejs wywołania zwrotnego. Jednym z elementów wejściowych podczas tworzenia elementów GUI jest implementacja tego interfejsu. W przypadku interakcji użytkownika element GUI wywołuje funkcję aktualizacji w tym interfejsie. Mają realną implementację i wdrożenie testowe.

2 - Użyj programów obsługi zdarzeń. Zarejestruj wszystkie elementy GUI za pomocą jednego lub wielu programów obsługi zdarzeń, a GUI wygeneruj zdarzenia w interakcji użytkownika. Mieć interfejs obsługi zdarzeń z dwiema implementacjami, ponownie jedną do rzeczywistego użytku i jedną do testowania.

Edytuj: whoops, brakujące wymaganie nr 1. Nigdy nie robiono tego z kontrolkami specyficznymi dla OSX, ale ogólnie istnieją dwa podejścia.

1 - utwórz skrypt lub aplikację, która generuje dane wejściowe podobne do użytkownika. Ma wadę polegającą na tym, że nie jest łatwo faktycznie sprawdzić GUI. Zamiast tego trzeba wygenerować dobre przypadki testowe, aby upewnić się, że wszystko, co powinno być, nie istnieje.

2 - utwórz interfejs z implementacją testową, która zastępuje warstwę renderowania i warstwę interfejsu. Jest to łatwiejsze w przypadku bibliotek takich jak SDL lub directFB, a mniej w takich, jak API OSX, API win32, itp.

Edytuj: odpowiadając na edytowane pytanie.

W przypadku swojej przykład za pomocą oddzielnych testowanie aplikacji i obsługi zdarzeń oto jak będzie wyglądało:

Aplikacja test jest prosty app lub skrypt, który zaczyna swój GUI, a następnie generuje mysz/klawiatura zdarzenia oparte na plikach wejściowych. Jak już powiedziałem, nigdy nie robiłem tego w OSX (tylko QNX). Przy odrobinie szczęścia będziesz w stanie generować zdarzenia myszy i klawiatury za pomocą API, ale będziesz musiał zapytać kogoś, czy jest to możliwe.

Stwórz więc dane wejściowe dla swojego testu. Aplikacja testowa przetworzy to, aby wiedzieć, co robić. Może to być prosty kod XML podobny do tego:

<testcase name="blah"><mouseevent x="120" y="175" type="click"/></testcase> 

lub jakakolwiek może być sekwencja myszy.

Kiedy twój skrypt wykona to polecenie, kliknie myszą na tym przycisku. Twój przewodnik zdarzeń odbierze to. Ale teraz powinieneś uruchamiać swoją aplikację z flagą --test lub somesuch, tak aby faktycznie korzystał z programu obsługi zdarzeń testowych. Zamiast robić to, co normalnie robi twoja aplikacja, program obsługi zdarzeń testowych może wykonać niestandardową akcję. Na przykład może wykonać niektóre z normalnych działań (nadal potrzebujesz interfejsu GUI, aby odpowiedzieć), a następnie wysłać wiadomość (przez gniazdo, potok, cokolwiek) do aplikacji testowej.

Twoja aplikacja testowa odczyta tę wiadomość i porówna ją z oczekiwaną. Więc teraz może twój testcase XML wygląda następująco:

<testcase name="blah"> 
    <mouseevent x="120" y="175" type="click"/> 
    <response>doMyItem() called</response> 
</testcase> 

Jeśli odpowiedź generowana z obsługi zdarzeń jest różny, to przypadek testowy nie powiodło się. Możesz wydrukować rzeczywistą odpowiedź, aby pomóc w debugowaniu.

Answer 2

Dwie zasady, dwie linki:

• sprawiają, że widok tak głupi, jak to możliwe, ze wzoru passive view: To sprawia, że ​​GUI łatwiej testować
• : Trust realizację Cocoa przycisków, menu, .. Ale sprawdź, czy target and action są poprawnie połączone, że bindings są zgodne z oczekiwaniami.

Answer 3

Czy zapoznałeś się z ramami dostępności? Powinno to umożliwić jednej aplikacji sprawdzenie interfejsu użytkownika innej aplikacji i generowanie zdarzeń interakcji podobnych do użytkownika.

Accessibility Overview