Sultana Core Motoko Package

A TypeScript library for interacting with the Sultana Core Motoko actor on the Internet Computer (IC) platform.

Setup

1. Create dfx identities

Create the required identities:

dfx identity new superadmin
dfx identity new owner1
dfx identity new worker1
dfx identity new customer1

2. Export PEM values

Export the PEM for each identity and copy the output:

dfx identity export superadmin
dfx identity export owner1
dfx identity export worker1
dfx identity export customer1

3. Configure .env

Paste each PEM value into the corresponding variable in your .env file:

IDENTITY_PEM="-----BEGIN EC PRIVATE KEY-----
...superadmin PEM here...
-----END EC PRIVATE KEY-----"

OWNER1_PEM="-----BEGIN EC PRIVATE KEY-----
...owner1 PEM here...
-----END EC PRIVATE KEY-----"

WORKER1_PEM="-----BEGIN EC PRIVATE KEY-----
...worker1 PEM here...
-----END EC PRIVATE KEY-----"

CUSTOMER1_PEM="-----BEGIN EC PRIVATE KEY-----
...customer1 PEM here...
-----END EC PRIVATE KEY-----"

Make sure to keep newlines inside the PEM value — wrap the value in double quotes and preserve the line breaks exactly as exported.

Tests

Tests are integration tests that run against a dedicated test canister on mainnet — no local replica is used.

Prerequisites

Complete the Setup section first. Then copy .env.example to .env and fill in CANISTER_ID and all PEM values.

Available test scripts

Each script redeploys the test canister before running.

| Script | Description | |---|---| | npm run test-suite | Full integration test — covers admin, profiles, service types, salons, HR, availability, booking, search, and visits | | npm run test-tomorrow | Same as test-suite but with referenceDate set to tomorrow | | npm run test-access-restrictions | Role-based access control tests | | npm run test-migration-simple | Data migration tests |

Notes

• Tests require an active internet connection and a valid CANISTER_ID in .env.
• After any write (update call), the IC needs a moment to propagate state — tests include a waitFor(5000) delay before subsequent reads to avoid non-deterministic results.
• If a test fails, the first thing to check is whether state had enough time to propagate. Rerun the test before investigating logic errors — transient propagation lag is the most common cause of false failures on mainnet.