Testing Guide - Salud Health

Overview

Salud uses a multi-layered testing approach to ensure reliability and security across the frontend, backend, and smart contracts.

Testing Philosophy

Quality Standards

Smart Contracts: Comprehensive test coverage (security-critical)
Backend: API endpoint validation and error handling
Frontend: Build verification and linting
Integration: Manual end-to-end testing

Test Pyramid

        /\        E2E Tests (Manual)
       /  \       - User flows
      /    \      - Cross-browser
     /      \     
    /--------\    Integration Tests (Manual/Automated)
   /          \   - API endpoints
  /            \  - Contract interactions
 /              \ 
/----------------\ Unit Tests (Automated)
                   - Contract transitions
                   - Utility functions
                   - Component rendering

Smart Contract Testing

The Leo smart contract has the most comprehensive test suite with 17 automated tests.

Running Contract Tests

cd salud_health_records
leo test

# Expected output:
# Test test_create_record ... ok
# Test test_record_types ... ok
# ... (17 tests)
# All tests passed ✓

Test Coverage

The contract test suite (tests/test_salud_health_records.leo) covers:

Record Creation Tests

test_create_record

Verifies basic record creation with valid inputs.Tests:

Record is created successfully
Owner is set to caller
Data fields are stored correctly
Record type is valid

test_record_types

Validates all 10 record type categories.Record Types Tested:

General Health
Laboratory Results
Prescriptions
Imaging/Radiology
Vaccination Records
Surgical Records
Mental Health
Dental Records
Vision/Ophthalmology
Other/Miscellaneous

test_invalid_record_type

Ensures invalid record types (0, 11+) are rejected.Expects: Assertion failure for out-of-range types

Record ID Tests

test_record_id_uniqueness

Verifies that different inputs produce unique record IDs.Tests:

Different data → different IDs
Different nonces → different IDs
Different patients → different IDs

test_record_id_determinism

Confirms same inputs always produce same ID.Tests:

Same patient + data + nonce = same ID
Useful for client-side ID computation

Access Grant Tests

test_grant_access

Tests basic access grant creation.Verifies:

Access token is generated
Grant is stored in mapping
Patient retains record ownership

test_access_token_generation

Validates access token uniqueness.Tests:

Different doctors → different tokens
Different nonces → different tokens
Same inputs → same token (deterministic)

test_duration_bounds

Checks duration clamping to valid ranges.Tests:

Minimum: 240 blocks (~1 hour)
Maximum: 40,320 blocks (~7 days)
Out-of-range values are clamped

Access Verification Tests

test_verify_valid_access

Tests successful verification with valid token.Flow:

Create record
Grant access to doctor
Verify access succeeds

test_verify_invalid_token

Ensures fake tokens are rejected.Tests:

Random token → verification fails
Wrong token for record → fails

test_verify_wrong_doctor

Prevents access by unauthorized doctors.Scenario:

Grant to Doctor A
Doctor B tries to access
Verification fails

test_verify_wrong_record

Ensures tokens are record-specific.Scenario:

Token for Record A
Used on Record B
Verification fails

Revocation Tests

test_revoke_access

Tests immediate access revocation.Flow:

Grant access
Revoke access
Verification fails
Access info shows is_revoked: true

test_full_flow

End-to-end integration test.Complete Flow:

Patient creates record
Patient grants access to doctor
Doctor verifies access (succeeds)
Patient revokes access
Doctor verification fails

Helper Function Tests

test_compute_record_id

Validates client-side ID computation helper.Purpose: Allows frontend to predict record IDs

test_get_access_info

Tests public access info retrieval.Returns:

Patient address
Doctor address
Record ID
Expiration time
Revocation status

Writing New Contract Tests

Example test structure:

// tests/test_salud_health_records.leo

@test
function test_your_feature() {
    // Setup: Create test data
    let patient: address = aleo1...;
    let doctor: address = aleo1...;
    
    // Execute: Call transition
    let record: MedicalRecord = create_record(
        1field, 2field, 3field, 4field,
        1u8,      // record_type
        100field, // data_hash
        42field,  // nonce
        false     // make_discoverable
    );
    
    // Assert: Verify results
    assert_eq(record.owner, patient);
    assert_eq(record.record_type, 1u8);
    assert(record.record_id != 0field);
}

Best Practices:

Test one thing per test function
Use descriptive function names
Add comments explaining what’s being tested
Test both success and failure cases
Verify security constraints

Backend Testing

The backend uses manual testing and verification.

Running Backend Tests

Start the Server

cd backend
npm start

Verify: Server starts without errors on port 3001

Test Health Endpoint

curl http://localhost:3001/api/health

Expected Response:

{
  "status": "ok",
  "message": "Salud Health Records API is running"
}

Test Wallet Generation

curl -X POST http://localhost:3001/api/wallet/generate

Expected Response:

{
  "success": true,
  "privateKey": "APrivateKey1...",
  "address": "aleo1...",
  "sessionId": "uuid-here"
}

Test Wallet Connection

curl -X POST http://localhost:3001/api/wallet/connect \
  -H "Content-Type: application/json" \
  -d '{
    "privateKey": "APrivateKey1zkp..."
  }'

Expected Response:

{
  "success": true,
  "address": "aleo1...",
  "sessionId": "uuid-here"
}

Test Record Creation

curl -X POST http://localhost:3001/api/records/create \
  -H "Content-Type: application/json" \
  -d '{
    "sessionId": "your-session-id",
    "encryptedData": "encrypted-medical-data",
    "recordType": 1
  }'

Backend Test Checklist

Manual API Testing with Postman

Collection Setup:

Base URL: http://localhost:3001
Headers: Content-Type: application/json

Test Scenarios:

Health Check
Generate Wallet
Create Record

GET /api/health

Expected: 200 OK
Body: { "status": "ok" }

POST /api/wallet/generate

Expected: 200 OK
Body: { "success": true, "privateKey": "...", "address": "..." }

Save: sessionId for subsequent requests

POST /api/records/create
Body: {
  "sessionId": "{{sessionId}}",
  "encryptedData": "test data",
  "recordType": 1
}

Expected: 200 OK or appropriate error

Frontend Testing

The frontend focuses on build verification and code quality.

Running Frontend Tests

cd frontend
npm run lint

# Checks for:
# - TypeScript errors
# - ESLint rule violations
# - React best practices
# - Unused imports/variables

Frontend Test Checklist

Manual UI Testing

Test on Multiple Browsers:

Chrome/Edge
Safari
Firefox
Mobile Safari
Mobile Chrome

Wallet connection
QR code camera access
LocalStorage persistence
Console errors

Integration Testing

End-to-End User Flows

Patient Creates Record

Test Flow:

Open app at http://localhost:5173
Connect wallet (or generate new)
Click “New Record” button
Enter medical data
Submit record
Verify success message
See record in list

Expected Result: Record appears in dashboard

Patient Shares Record

Test Flow:

Click “Share” on a record
Enter doctor address (or use default duration)
QR code displays
Verify expiration countdown shows
Screenshot QR code for doctor test

Expected Result: Valid QR code generated

Doctor Scans and Views

Test Flow:

Navigate to /doctor route
Connect doctor wallet
Click “Scan QR Code”
Grant camera permission
Scan patient’s QR code
View decrypted record
Verify expiration timer

Expected Result: Record displays with countdown

Access Expiration

Test Flow:

Create record with 1-hour duration
Share with doctor
Wait for expiration (or modify block height in demo)
Doctor attempts to view
Verify “Access expired” error

Expected Result: Access denied after expiration

Cross-Platform Testing

Device Matrix:

Device	OS	Browser	Priority
iPhone 12+	iOS 15+	Safari	High
iPhone 12+	iOS 15+	Chrome	Medium
Android	11+	Chrome	High
Desktop	macOS	Chrome/Safari	High
Desktop	Windows	Chrome/Edge	High
Desktop	Linux	Firefox	Medium

Testing Best Practices

Before Committing

Run All Checks

# Frontend
cd frontend
npm run lint
npm run build

# Backend
cd ../backend
npm start  # Verify starts
# Ctrl+C to stop

# Contract (if changed)
cd ../salud_health_records
leo test

Manual Testing

Test the feature you changed
Test related features
Check for console errors
Verify mobile responsive (if UI change)

Document Changes

Update documentation if needed
Add comments for complex logic
Update API docs if endpoints changed

Before Pull Request

Continuous Testing

During Development

Frontend (with HMR):

cd frontend
npm run dev

# Changes auto-reload
# Check browser console after each change
# Verify functionality manually

Backend (with nodemon):

cd backend
npm run dev

# Server auto-restarts on changes
# Check terminal for errors
# Re-test endpoints after changes

Contract (iterative):

cd salud_health_records

# Make changes to src/main.leo
leo build
leo test

# Fix errors, repeat

Test Data

Demo Mode Test Data

Sample Private Keys (Testnet Only):

APrivateKey1zkp... (generate new for testing)

Sample Medical Records:

{
  "title": "Annual Physical Exam",
  "data": "Blood pressure: 120/80, Heart rate: 72 bpm, Temperature: 98.6°F",
  "recordType": 1
}

{
  "title": "Lab Results - Cholesterol",
  "data": "Total: 180 mg/dL, HDL: 55 mg/dL, LDL: 100 mg/dL",
  "recordType": 2
}

Sample Doctor Address (for testing):

aleo1... (use generated address from "Generate New")

Debugging Tests

Contract Test Failures

# Run with verbose output
leo test --verbose

# Read assertion error messages carefully
# Check expected vs actual values
# Verify test setup matches contract logic

Backend Issues

// Add console logs in server.js
console.log('Request body:', req.body);
console.log('Session data:', sessions.get(sessionId));

// Check for:
// - Missing parameters
// - Type mismatches
// - Aleo SDK errors

Frontend Issues

// Browser DevTools Console
// Check for:
// - API call failures (Network tab)
// - State updates (React DevTools)
// - LocalStorage data (Application tab)
// - Console errors/warnings

Next Steps

Contributing Guide

Learn how to submit tested contributions

Local Setup

Set up your testing environment

Architecture

Understand what you’re testing

API Reference

Test API endpoints comprehensively

Security

Help

Development

​Overview

​Testing Philosophy

​Quality Standards

​Test Pyramid

​Smart Contract Testing

​Running Contract Tests

​Test Coverage

​Record Creation Tests

​Record ID Tests

​Access Grant Tests

​Access Verification Tests

​Revocation Tests

​Helper Function Tests

​Writing New Contract Tests

​Backend Testing

​Running Backend Tests

​Backend Test Checklist

​Manual API Testing with Postman

​Frontend Testing

​Running Frontend Tests

​Frontend Test Checklist

​Manual UI Testing

​Integration Testing

​End-to-End User Flows

​Cross-Platform Testing

​Testing Best Practices

​Before Committing

​Before Pull Request

​Continuous Testing

​During Development

​Test Data

​Demo Mode Test Data

​Debugging Tests

​Contract Test Failures

​Backend Issues

​Frontend Issues

​Next Steps

Contributing Guide

Local Setup

Architecture

API Reference

Build docs developers (and LLMs) love

Overview

Testing Philosophy

Quality Standards

Test Pyramid

Smart Contract Testing

Running Contract Tests

Test Coverage

Record Creation Tests

Record ID Tests

Access Grant Tests

Access Verification Tests

Revocation Tests

Helper Function Tests

Writing New Contract Tests

Backend Testing

Running Backend Tests

Backend Test Checklist

Manual API Testing with Postman

Frontend Testing

Running Frontend Tests

Frontend Test Checklist

Manual UI Testing

Integration Testing

End-to-End User Flows

Cross-Platform Testing

Testing Best Practices

Before Committing

Before Pull Request

Continuous Testing

During Development

Test Data

Demo Mode Test Data

Debugging Tests

Contract Test Failures

Backend Issues

Frontend Issues

Next Steps