/
Testing and Debugging

Testing and Debugging

Testing

Prerequisites

User accounts:

  • A user without TIXNGO ticket

  • A user with TIXNGO ticket

Login to TIXNGO Backoffice to inject tickets for the user

iOS

  1. Clone demo app from github

  2. Setup cocoapods and run "pod install"

  3. Run app

  4. Login account

    1. by an account with ticket

    2. by an account without ticket

Android

  1. Clone demo app from github

  2. Setup config same link

  3. Run app

  4. Login

    1. by an account with ticket

    2. by an account without ticket

Test Scenarios Checklist

Use the following scenarios to validate that your integration with the TIXNGO SDK is functioning correctly. This checklist ensures proper handling of authentication, ticket visibility, transfer flows, session limits, and token expiration recovery.

1. Login Scenarios

1.1 Login with a Ticketed Account

  • Precondition: The test user must have at least one active or past ticket.

  • Steps:

    • Launch the Fan App.

    • Login using valid credentials.

    • Navigate to the TIXNGO SDK screen.

  • Expected Result:

    • SDK loads successfully.

    • Ticket list is visible.

    • No errors are returned.

1.2 Login with an Account without Tickets

  • Precondition: The test user has never owned a ticket in the TIXNGO system.

  • Steps:

    • Launch the Fan App.

    • Login using a valid user account.

    • Attempt to access the TIXNGO SDK screen.

  • Expected Result:

    • SDK returns error: 403, NO_TICKET_ELIGIBILITY.

    • Fan App displays a user-friendly message and prevents SDK access.

2. Logout and Re-Login Scenarios

2.1 Logout User

  • Steps:

    • From the Fan App, trigger the logout flow.

    • Ensure that TIXNGO SDK logout() is called.

  • Expected Result:

    • User is logged out from both Fan App and SDK.

    • SDK local session data is cleared.

2.2 Login Again After Logout

  • Steps:

    • Re-authenticate with the same user account.

    • Access the SDK.

  • Expected Result:

    • SDK initializes successfully.

    • Previously accessible tickets are still shown (if any).

3. Token Expiration Handling

Refer to Token Lifecycle and Integration

3.1 Resume After Token Expiration

  • Precondition: User is logged in, token has a short TTL (e.g., 5 mins).

  • Steps:

    • Login to the Fan App.

    • Wait until the access token expires (without interacting).

    • Reopen the app and access the SDK.

  • Expected Result:

    • SDK triggers token refresh via Fan App.

    • Fan App provides refreshed tokens to the SDK.

    • SDK resumes operation without user logout.

Test both “happy case” (refresh successful) and degraded case (refresh denied or no internet).

  • Successful Refresh ("Happy Case"):
    Ensure that when the token expires and the device is online, the Fan App is able to refresh the token via the Identity Provider (IDP) and pass the new credentials to the SDK. The SDK should resume API calls automatically, and no user interruption should occur.

  • Degraded Refresh ("Failure Case"):
    Simulate two types of failures:

    1. Explicit Token Refresh Denial (e.g., refresh token is invalid or revoked):
      The Fan App should notify the SDK of the denial, and the SDK must log out the user and clear all cached data.

    2. Temporary Failure (e.g., no internet connection):
      The Fan App should inform the SDK that the refresh failed but was not denied. The SDK should enter offline mode, preserve cached tickets, and disable online features until connectivity is restored.

4. Session & Device Limits

4.1 Exceed Session or Device Limits

Refer to Authentication & Security

  • Precondition: Backoffice session limit (e.g., 2 sessions) is configured for the user.

  • Steps:

    • Login with the same user on two devices (e.g., iPhone + Android) → OK.

    • Attempt login on a third device.

  • Expected Result:

    • Login is rejected.

    • SDK returns error:

      • 403, MAX_NUMBER_SECURITY_TOKEN for session limit

      • 403, TOO_MANY_REGISTERED_DEVICES for device limit

    • Fan App displays an appropriate error message.

5. Ticket Transfer Scenarios

5.1 Send a Ticket to Another User

  • Precondition: Logged-in user owns at least one transferrable ticket.

  • Steps:

    • Access TIXNGO SDK.

    • Initiate a ticket transfer to another valid user.

  • Expected Result:

    • Transfer request is sent successfully.

    • Ticket enters “pending transfer” state.

5.2 Accept a Transferred Ticket

  • Precondition: Receiving user must be logged in to the Fan App with no ticket yet.

  • Steps:

    • Login with the receiving user.

    • Navigate to the TIXNGO SDK screen.

    • Accept the pending transfer.

  • Expected Result:

    • Ticket is successfully added to the receiver's wallet.

    • Transfer status is updated accordingly.

6. DeepLink Test

  • Tap on a notification with an SDK deeplink (e.g., ticket detail link).

  • Expected: SDK opens the correct view.

7. Offline Mode Ticket Viewing

  • Login to the Fan App with tickets.

  • Go offline.

  • Access the SDK.

  • Expected: Tickets are still visible (read-only).

Debugging

Enable debug mode  'isEnableDebug: true'

We recommend using TIXNGO Backoffice during testing, in case of errors the mobile logs in the Backoffice provide the error log and the JWT token which can decoded.

© TIXNGO 2023 - Login