Skip to main content

Sandbox Clients Test Cases

This document outlines the predefined client data available in the sandbox environment for testing client-related functionality.

Overview​

The sandbox environment provides three predefined clients with different characteristics to test various scenarios. These clients are accessible through both username and ID-based searches.

Predefined Clients​

1. Normal Client (John Doe)​

  • Username: 6671231234 or john.doe@example.com
  • Client ID: ID_6671231234
  • Full Name: John Doe
  • Available Amount: 5000
  • Can Buy: true
  • First Company Sale: false
  • Line Extension Available: 0

Use Case: Standard client with good credit line and purchase capability.

2. New Client (Jane Doe)​

  • Username: 6671231235 or jane.doe@example.com
  • Client ID: ID_6671231235
  • Full Name: Jane Doe
  • Available Amount: 2000
  • Can Buy: true
  • First Company Sale: true
  • Line Extension Available: 0

Use Case: New client making their first purchase with the company.

3. Cannot Buy Client (Johnny Doe)​

  • Username: 6671231236 or johnny.doe@example.com
  • Client ID: ID_6671231236
  • Full Name: Johnny Doe
  • Available Amount: 1000
  • Can Buy: false
  • First Company Sale: false
  • Line Extension Available: 0

Use Case: Client with restricted purchase capability (blocked or insufficient credit).

Special Store Configuration​

Store with Extension Available​

  • Store ID: eeeeeeee-eeee-eeee-eeee-eeeeaeeeeeee
  • Feature: Line extension available for clients

Use Case: Testing line extension functionality.

Test Cases​

Test Case 1: Search Client by Username (Found)​

Endpoint: GET /preview/client-search

Query:

?username=6671231234

Expected Response:

{
  "id": "ID_6671231234",
  "availableAmount": 5000,
  "canBuy": true,
  "firstCompanySale": false,
  "fullName": "John Doe",
  "lineExtensionAvailable": 0,
  "phoneCode": "+52",
  "phoneNumber": "6671231234",
  "email": "john.doe@example.com"
}

Test Case 2: Search Client by Username (Not Found)​

Endpoint: GET /preview/client-search

Query:

?username=9999999999

Expected Response:

null

Test Case 3: Confirm Client (Normal Client)​

Endpoint: POST /sale-request/confirm-client

Payload:

{
  "clientId": "ID_6671231234"
}

Expected Response:

true

Test Case 4: Confirm Client (New Client)​

Endpoint: POST /sale-request/confirm-client

Payload:

{
  "clientId": "ID_6671231235"
}

Expected Response:

true

Test Case 5: Confirm Client (Cannot Buy Client)​

Endpoint: POST /sale-request/confirm-client

Payload:

{
  "clientId": "ID_6671231236"
}

Expected Response:

true

Note: Confirmation succeeds even if client cannot buy. Purchase restrictions are enforced at sale confirmation.

Test Case 6: Confirm Client (Not Found)​

Endpoint: POST /sale-request/confirm-client

Payload:

{
  "clientId": "ID_9999999999"
}

Expected Response:

Error: 404 Not Found

{
  "message": "Client ID_9999999999 not found",
  "errorCode": "SALE-COMPONENT-01",
  "statusCode": 404
}

Error Scenarios​

Client Not Found​

  • Trigger: Using non-existent username or client ID
  • Error Code: SALE-COMPONENT-01
  • HTTP Status: 404

Too Many Client Searches​

  • Trigger: Exceeding 10 client searches for a single sale request
  • Error Code: SALE-COMPONENT-07
  • HTTP Status: 400

Usage Guidelines​

  1. Use valid usernames (6671231234 or john.doe@example.com, 6671231235 or jane.doe@example.com, 6671231236 or johnny.doe@example.com) to test successful searches
  2. Use invalid usernames (any other value) to test "not found" scenarios

For Testing Client Confirmation​

  1. Use valid client IDs to test successful confirmations
  2. Use invalid client IDs to test error handling

For Testing Purchase Scenarios​

  1. Normal Client: Test standard purchase flows
  2. New Client: Test first-time buyer flows and potential special handling
  3. Cannot Buy Client: Test purchase restriction enforcement during sale confirmation

For Testing Line Extensions​

  1. Use the special store ID eeeeeeee-eeee-eeee-eeee-eeeeaeeeeeee when testing line extension features

Implementation Notes​

  • Client data is hardcoded in the sandbox environment for consistent testing
  • Username searches are case-sensitive
  • Client IDs follow the format ID_XXXXXXXXXX
  • The canBuy flag is enforced during transaction processing, not during client confirmation
  • Line extension functionality is store-dependent

Integration with Sale Request Flow​

  1. Search Phase: GET /preview/client-search?username=<value>
  2. Confirmation Phase: POST /sale-request/confirm-client with { clientId }
  3. Sale Phase: Client restrictions (canBuy: false) may cause transaction failures

This deterministic client data ensures consistent test results across different environments and test runs.