Mój projekt iOS ma pięć schematów: rozwój lokalny, integracja, kontrola jakości, demonstracja i produkcja. Każdy schemat używa różnej konfiguracji do kontrolowania takich rzeczy, jak częstotliwość odpytywania sieci, punkty końcowe API, analizy i tak dalej.Xcode/iOS: testy jednostek, schematy i konfiguracje
Podobnie mamy pięć odpowiednich celów: rozwój lokalny, integracja, kontrola jakości, demonstracja i produkcja. Każdy cel ma kilka Ustawienia zdefiniowane przez użytkownika budować, które zawierają klucze API wartości numeryczne dla czasu itd
naszej aplikacji za Info.plist plik wykorzystuje zmienne aplikacji, takich jak ${SOME_ENDPOINT_URL} do remisu na odpowiedniego użytkownika zdefiniowane ustawienia budować.
Aby pobrać zmienne, zrobić coś jak następuje:
[[[NSBundle mainBundle] infoDictionary] valueForKey:@"Some Endpoint URL"]
To by odpowiadać zdefiniowanej przez użytkownika budowy ustawienie, tak:
"Some Endpoint URL" = ${SOME_ENDPOINT_URL}
jestem teraz patrząc na to, jak aby odpowiednio skonfigurować projekt w celu wykonania testów jednostkowych i logicznych.
Aby zbudować testy mające na celu sprawdzenie, czy środowiska są poprawnie skonfigurowane, nie jestem pewien, jaka jest najlepsza praktyka.
- Czy można poprawnie zbudować pięć dodatkowych celów specyficznych dla testu dla każdego środowiska?
- A może lepiej zastąpić ustawienie "Argumenty akcji uruchomienia" dla komponentu testowego dla każdego schematu i podać coś w rodzaju argumentu, aby określić, którego schematu szukamy?
- Czy istnieją już odniesienia do konfigurowania testów jednostek i logiki dla projektów iOS z wieloma środowiskami? Złożoność tego projektu wydaje się przekraczać zakres większości dokumentacji.
Jabłko utrzymuje zakaz podejmowania wstecznie kompatybilne zmiany całego systemu Cele/Schematy - Myślę, że powodem nie jesteś znalezienie Docs to, że Apple zamierza/spodziewa się, aby więcej z nich idzie do przodu, i ma nadzieję, że uniknie flaku, który otrzymają. Ktoś z Apple wydaje się szczególnie nienawidzić Celów, więc osobiście podchodziłbym do podejścia "wykorzystuj argumenty" - Cele mogą być niedokładne (ponownie :() – Adam
Zamiast mieć tak wiele różnych celów, dlaczego nie mieć tylko jednego celu? i pięć konfiguracji? Zamiast debugowania i wydania miałbyś LocalDev, Integ, QA, Demo, Prod. Możesz wtedy stworzyć pięć schematów, które budują ten sam cel, ale z inną konfiguracją –
@JacobLukas czy znasz dobry samouczek na to, co opisujesz Zawsze unikałem schematów, ale brzmi jak mogą być naprawdę przydatne – DogCoffee