2009-01-05 17 views
6

Dla celów testowania jednostkowego chciałbym utworzyć docelowy projekt iPhone'a w Xcode, który zawierałby wszystkie pliki aplikacji do wydania, oraz kilka dodatkowych plików zawierających kod przydatny do testowania jednostek interfejsu użytkownika.Czy można utworzyć cel "nadzbiór" w Xcode?

Mogę to zrobić przez skopiowanie oryginalnego celu aplikacji; Problem polega jednak na tym, że za każdym razem, gdy dodaję nowy plik źródłowy do celu aplikacji, muszę go również dodać do celu UnitTestUI. To nie jest nic wielkiego, tylko niewygodne, aby zawsze pamiętać, aby dodać pliki do obu celów.

Czy istnieje sposób na skonfigurowanie zależności, aby każdy plik dodany do pierwotnego celu aplikacji był również automatycznie dodawany do celu testu jednostkowego?

Odpowiedz

4

W Xcode można tworzyć cele, które bezpośrednio od siebie zależą. Istnieje wiele celów dotyczących budowania produktów innych niż produkty, które mogą pomóc w tym zakresie w kategorii Inne podczas dodawania nowego celu, w zależności od tego, jak proste i skomplikowane jest twoje ustawienie. Tworzenie specyficznych celów dla testów jednostkowych z bezpośrednią zależnością od głównego celu projektu jest bardzo powszechne i jest udokumentowane przez Apple i na wielu blogach.

W Twojej sytuacji może być jednak konieczne wprowadzenie wielu ulepszeń w nowym celu testowania interfejsu użytkownika, ale po jego skonfigurowaniu będzie bardzo łatwy w utrzymaniu. Nie znając dokładnie sytuacji, że to niemożliwe, aby dać odpowiedź krok po kroku, ale tutaj są ogólne wytyczne (dostosować do własnych sytuacji):

  1. Utwórz kopię swojego pierwotnego celu, ponieważ większość swojego ustawienia będą takie same.
  2. Wybierz swój nowy cel i otwórz Inspektora (⌘I)
  3. Pod bezpośrednie współzależności, kliknij przycisk + i wybierz swój główny cel.
  4. Skonfiguruj nowy cel zgodnie z potrzebami, z dodatkową dokumentacją/źródłem/regułami lub cokolwiek innego.

Jeśli wolisz przeciąganie i upuszczanie rzeczy wokół, można także przeciągnąć swój pierwotny cel (spod Targets trójkąt) do nowego celu, a zostanie ona automatycznie skonfigurować zależność.

Teraz wybierz cel testowy jako aktywny cel i zawsze będzie budowany zgodnie z tymi regułami. Ponadto, jeśli dodasz/zmienisz źródło w głównym celu, zostanie on prawidłowo odbudowany podczas budowania twojego celu testowego ... nie musisz pamiętać o dodaniu pliku źródłowego do celu testowego. Proponuję poświęcić trochę czasu na przeczytanie różnych dokumentów Xcode i zabawę z wieloma dostępnymi szablonami docelowymi ... na dłuższą metę naprawdę pomaga to w lepszym wykorzystaniu produktu. Jest wiele fajnych rzeczy, które można zrobić całkiem łatwo w Xcode, jeśli wiesz jak, nawet przy bardzo dużych lub złożonych projektach.

+1

Dziękuję za tę bardzo pomocną odpowiedź! – thrusty

+0

Świetna odpowiedź. Początkowo myślałem, że mogę usunąć moje połączone biblioteki również z nowego celu, ale nic takiego 'git reset --hard''s nie naprawi. –

0

Nie, nie ma. Czy jest jakiś szczególny powód, dla którego chcesz, aby każdy pojedynczy plik w twoim celu testu jednostkowego? Obejmowałoby to main.m i wszystkie klasy, których nie testujesz (na przykład być może twoje klasy widoku). W rzeczywistości, jeśli main.m jest uwzględnione w twoim teście jednostkowym, to w jaki sposób Twój test jednostki działałby poprawnie?

+0

Muszę wyjaśnić, że cel ten ma na celu sprawdzenie kodu, który jest zależny od dostępności całego kontekstu aplikacji. (Takich jak niektóre UIViewControllers.) Jako takie jest bardziej jak ramy testu interfejsu użytkownika, i ma na celu pokrycie rzeczy, których nasze inne "bezgłowe" testy jednostkowe nie są w stanie pokryć. – thrusty

+0

Oczywiście, cele mogą być bezpośrednimi zależnościami między sobą. –

0

Rozwiązałem problem, budując większą część mojej aplikacji jako bibliotekę statyczną, która jest połączona z celami testów aplikacji i jednostek.

Cele w moim projekcie wyglądać następująco:

  • libMyApp
    • skompilować .m plików
  • MyApp.app
    • libMyApp (zależność)
    • link z biblioteki: libMyApp.a
  • UITest.app
    • libMyApp (zależność)
    • link z biblioteki: libMyApp.a

ten sposób mogę dodać .m pliki tylko do "libMyApp" target i mieć je dostępne zarówno w aplikacji, jak i testach, i nie trzeba ich nawet rekompilować.

Jedynym problemem jest to, że biblioteka statyczna nie obsługuje kategorii Objective-C, więc nadal muszę dodawać je do każdego celu osobno.

Powiązane problemy