Czyszczenie zakupów w piaskownicy zakupów w aplikacji na iOS dla użytkownika testowego

116

Czy ktoś ma jakieś pomysły, jak zresetować i / lub wyczyścić piaskownicę zakupów w aplikacji na iOS?

Mam aplikację, którą testuję przy użyciu piaskownicy i chciałbym przetestować nowe zakupy bez konieczności tworzenia nowego użytkownika testowego za każdym razem, gdy coś kupię.

Jeśli tego nie zrobię, (oczywiście) zawsze otrzymuję komunikat, że element do zakupu w aplikacji został już zakupiony, gdy kliknę przycisk kup w mojej aplikacji.

RandomIOSDeveloper
źródło

Odpowiedzi:

75

IMO są 3 rzeczy, które możesz zrobić, aby testowanie materiałów nieużywalnych było znośne:

  1. Możesz mieć wiele kont testowych powiązanych z jednym adresem e-mail. Na przykład Gmail pozwala na dodanie ciągu znaków „plus” do wiadomości e-mail, aby utworzyć aliasy dla adresu : więc [email protected]i [email protected]oba tak naprawdę po prostu przejdź do [email protected]. Prawdopodobnie inne hosty poczty e-mail robią to samo. Podczas tworzenia konta testowego musisz podać: imię, nazwisko, adres e-mail, hasło, tajne pytanie, tajną odpowiedź, datę urodzenia i kraj sklepu iTunes. Możesz podać dokładnie te same dane (w tym hasło) dla [email protected]i, [email protected]a będziesz mieć dwa konta testowe. Wreszcie w swojej [email protected]skrzynce odbiorczej otrzymasz dwa e-maile weryfikacyjne od Apple, aby potwierdzić oba konta testowe.

  2. Powiedz, że masz materiał niezużywalny o identyfikatorze produktu @ „Extra_Levels”. Zamiast wpisywać @ "Extra_Levels" we wszystkich metodach (requestProduct, buyProduct, ...), po prostu napisz PRODUCT_ID1i umieść jakiś plik nagłówkowy #define PRODUCT_ID1 @"Extra_Levels"(bez średnika!), Wtedy preprocesor przeszuka PRODUCT_ID1 i podstawi go za @ "Extra_Levels". Utworzenie nowego nieużywalnego materiału o nazwie @ "Extra_Levels_01" i zmiana #define będzie równie dobre, jak zresetowanie zakupów dla wszystkich użytkowników testowych.

  3. Jak wskazał appsmatics, możesz przetestować poprawne zachowanie swojego kodu, kupując niezużywalny IAP, najpierw używając zużywalnego IAP (aby użytkownik testowy mógł dokonać tylu zakupów, ile potrzeba), aby pozbyć się niektórych błędów. Oczywiście po tym należy również przetestować kod za pomocą rzeczywistego, nie zużywalnego IAP.

Roberto Canogar
źródło
17
Wow, nigdy nie wiedziałem o tej super tajnej funkcji Gmaila. Jak przydatne!
bobobobo
4
Właśnie się dowiedziałem, że tak naprawdę nie musisz weryfikować swojego adresu e-mail użytkownika testowego. możesz po prostu wpisać [email protected] z określeniem hasła (że nadal będziesz używać hasła w trybie piaskownicy) i nadal będzie działać. Właśnie testowałem zeszłej nocy.
wkrótce
3
Sztuczka PLUS SIGN dla aliasów e-mail to nie tylko kwestia Gmaila. To bardzo stara tradycja wśród serwerów pocztowych, sięgająca dziesięcioleci. Ale nigdy nie został uwzględniony w żadnej specyfikacji e-mail. Przetestuj go więc na swoim konkretnym serwerze e-mail, aby mieć pewność, że zna się na tej funkcji.
Basil Bourque
2
Nie sądzę, że nie da się rozliczać zakupów w aplikacji na koncie testowym;) Viva Apple :)
Bartłomiej Semańczyk
12
+adresów e-mail nie można już używać do rejestracji w celu uzyskania Apple ID.
pkamb
32

O ile wiem, nie możesz tego zrobić. Backend piaskownicy działa jak prawdziwe konto - po zakupie jest kupowany (dzięki czemu możesz przetestować przywracanie). Powinieneś robić większość swojego rozwoju z wyrzuconymi elementami sklepu, a kiedy zaczniesz testować go w rzeczywistości, po prostu spodziewaj się utworzenia kilku kont testowych.

Ben Zotto
źródło
3
Zgadzam się z samvermette, to szaleństwo, że testy tak bardzo przypominają prawdziwy sklep. Musi być przynajmniej sposób na wyczyszczenie zakupów w piaskownicy. Aby zrobić kilka zakupów dla tego samego użytkownika w celu przetestowania, dodałem również materiał eksploatacyjny.
appsmatics
4
@samvermette Jedyna różnica polega na SKPaymentTransactionStateRestoredtym, że zamiast tego wracasz ze sklepu z aplikacjami SKPaymentTransactionStatePurchased. Ponieważ nie używasz tutaj prawdziwych pieniędzy, do wszystkich celów i celów, SKPaymentTransactionStateRestoredjest to w 100% równoważne z SKPaymentTransactionStatePurchasedtestowaniem. Zresetowanie stanu aplikacji na „niekupiony” zależy tak naprawdę od Ciebie (po prostu usuń odpowiedni wpis pęku kluczy lub cokolwiek, czego używasz do buforowania tego „kupionego przez użytkownika X”)
bobobobo
10

Mam 2 elementy do zakupu w aplikacji. 1 do produkcji. a drugi do testów. kiedy muszę „wyczyścić”, usuwam element w aplikacji i tworzę nowy (15 sekund w itunes connect i 1 sekunda na zmianę identyfikatora produktu w kodzie)

jeśli nie muszę testować „nowego użytkownika”, używam produkcji w elemencie aplikacji.

user1105951
źródło
Tak, wykonanie nowej kopii produktu i zmiana nazwy produktu w kodzie (prawdopodobnie po #definiowaniu go) wydaje się zdecydowanie najłatwiejszym rozwiązaniem dla realistycznego testowania.
JulianSymes
7

Cóż, technicznie nie potrzebujesz tego.

Jeśli dostaniesz SKPaymentTransactionStateRestored, jest to w 100% równoważne z weryfikacją przez sklep z aplikacjami użytkownika i przyznaniem mu zakupu. Mam włącznik typu:

- (void)paymentQueue:(SKPaymentQueue *)queue updatedTransactions:(NSArray *)transactions
{
  for( SKPaymentTransaction *purch in transactions )
  {
    switch( purch.transactionState )
    {
      case SKPaymentTransactionStateRestored:
        info( "PURCHASE RESTORE" ) ;
        // fall thru
      case SKPaymentTransactionStatePurchased:
        [[SKPaymentQueue defaultQueue] finishTransaction:purch];
        // Do regular changes to app state for this purchase,
        // register in keychain, etc.
        break ;

       //.. other cases
     }
  }
}

Kwestia logiki aplikacji / odebrania zakupu jest prosta: jeśli buforujesz zakupy w pęku kluczy, usuń pęku kluczy. Jeśli robisz to w inny sposób, po prostu zmień stan lokalnej aplikacji, aby udawać, że użytkownik nigdy wcześniej jej nie kupił. Okno dialogowe z prośbą o zakup jest nadal dokładnie takie samo, jedyną różnicą jest to, że gdy klikniesz TAK, SKPaymentTransactionStateRestoredzamiast tego otrzymaszSKPaymentTransactionStatePurchased .

bobobobo
źródło
5

Usunięcie aplikacji i ponowna instalacja działa również w przypadku testowania w piaskownicy. Zależy to oczywiście od aplikacji, ale testuję aplikację opartą na subskrypcji, którą w tej chwili kupuje tylko podczas rejestracji, więc było to najłatwiejsze rozwiązanie.

Christopher Larsen
źródło
3

Sprawdź SimStoreKit . To „symulowana wersja StoreKit dla iPhone'a, do testowania interfejsów użytkownika sklepu w symulatorze iPhone'a, a nawet na urządzeniu bez konieczności konfigurowania IAP w Connect”.

SimStoreKit przechowuje zakupy w ustawieniach domyślnych użytkownika pod kluczem ILSimSKTransactions. Aby wyczyścić wszystkie zakupy, które możesz zrobić:

[[NSUserDefaults standardUserDefaults] removeObjectForKey:@"ILSimSKTransactions"]

W symulatorze możesz po prostu usunąć aplikację i zainstalować ją ponownie.

Z powodzeniem użyłem SimStoreKit do debugowania strony sklepu mojej aplikacji przed testowaniem w piaskownicy. Piękno tej biblioteki polega na tym, że można ją skonfigurować tak, aby używała tych samych nazw klas, co prawdziwy framework StoreKit (robiąc to #define ILSimReplaceRealStoreKit 1przed wykonaniem #include <ILSimStoreKit.h>).

W plikach źródłowych, do których potrzebuję dostępu do StoreKit, dołączam ten plik nagłówkowy:

#import <TargetConditionals.h>

#if TARGET_IPHONE_SIMULATOR
    #define kILSimAllowSimulatedStoreKit 1
    #define ILSimReplaceRealStoreKit 1
    #import <ILSimStoreKit.h>
#else
    #import <StoreKit/StoreKit.h>
#endif

Ma to wpływ na używanie SimStoreKit, gdy uruchamiam na symulatorze i prawdziwego StoreKit, gdy uruchamiam na urządzeniu.

Emile Cormier
źródło
nie mogłem zmusić tego do pracy. Otrzymuję błąd kompilacji. Skopiowałem wszystkie pliki z zip do mojego projektu i zastąpiłem wszystkie #import <StoreKit / StoreKit.h> na #define ILSimReplaceRealStoreKit 1 #import "ILSimStoreKit.h"
Jay Q.
Potrzebujesz tylko plików zaczynających się od ILSimSK. Pozostałe rzeczy dotyczą aplikacji demonstracyjnej. Być może powinieneś zadać pytanie z dokładnym błędem, który otrzymujesz. „Otrzymuję błąd kompilacji” niewiele mówi.
Emile Cormier
-1

alternatywnie, aby utworzyć rozwiązanie dla wielu użytkowników testowych, możesz utworzyć wiele testów w zakupach aplikacji w iTunes Connect, a następnie nie musisz zmieniać konta użytkownika.

Adobels
źródło
1
Powody głosów przeciw są następujące: 1. To nie jest dobre rozwiązanie, ponieważ możesz próbować przetestować konkretne rozwiązanie do zakupu w aplikacji, które może wymagać wielu scenariuszy z logowaniem użytkownika aplikacji i dostępnością zawartości na różnych urządzeniach / platformach. 2. Tworzenie wielu zakupów testowych jest równie (w rzeczywistości bardziej) żmudne, jak tworzenie wielu kont testowych. 3. Również odpowiedź nie jest dobrze sformatowana.
mickeymoon
-1

Po prostu korzystaj z tego samego konta testowego, przywracając zakupy, a nie kończąc nowe. W końcu, niezależnie od tego, czy zaczniesz nowy zakup, czy przywrócisz stary, TWOJA APLIKACJA zrobi to samo (przynajmniej początkowo może interfejs użytkownika zaktualizuje się inaczej po zakończeniu). Apple to ludzie inaczej radzący sobie w różnych sytuacjach - nie martw się o to.

Umieść logikę dostawy w przypadku SKPaymentTransactionStateRestored w ramach implementacji tej metody do testowania:

- (void)paymentQueue:(SKPaymentQueue *)queue
 updatedTransactions:(NSArray *)transactions;

Następnie pamiętaj, aby umieścić tę logikę dostawy w sprawie SKPaymentTransactionStatePurchased.

Na koniec, ponieważ większość z nas jest w różnym stopniu obsesyjno-kompulsywna, zrób ostatni test z nowym kontem (nie jest to wielka sprawa, aby zrobić drugie dla absolutnej pewności).

Ostatnia rzecz, na którą należy zwrócić uwagę: rozważ stanowisko Apple. Gdyby wystąpił problem z programistami, którzy musieli tracić czas na tworzenie dziesiątek lub setek kont, aby dokładnie przetestować IAP, rozwiązaliby problem. Nie ma problemu.

ArthurVonBabylon
źródło