Testing Strategy

Relevant source files

The following files were used as context for generating this wiki page:

• test/fire_event.sh
• test/demo.html
• README.md
• PROJECT_OUTLINE.md
• packages/analytics-web/events/auto.js
• app/workers/eventWorker.ts

The testing strategy for Glimpse focuses on validating the end-to-end flow of real-time analytics events, from client-side capture to backend processing and storage. The strategy utilizes a combination of automated shell scripts for API load simulation, a comprehensive HTML demo for manual SDK verification, and internal worker logging to verify data integrity.

Sources: PROJECT_OUTLINE.md:144-154, README.md:155-163

Manual SDK Verification

Glimpse provides a dedicated demonstration environment to test the analytics-web SDK's ability to capture various user interactions. This environment allows developers to verify both automatic and manual event triggers in a real browser context.

Interaction Testing

The demo.html file serves as a testbed for several categories of events:

Test Category	Description	Implementation Detail
Manual Tracking	Verification of custom event names and property objects.	tracker.track(eventName, properties)
Auto-Tracked Attributes	Testing elements with the data-track attribute.	data-track-name attribute mapping
Visibility Tracking	testing IntersectionObserver logic for specific sections.	data-track-view attribute
Error Handling	Simulation of runtime exceptions and promise rejections.	window.addEventListener('error', ...)
File Downloads	Validation of click listeners on specific file extensions.	Detection of .pdf, .zip, .exe, etc.

Sources: test/demo.html:36-115, packages/analytics-web/events/auto.js:46-77

SDK Event Flow

The following diagram illustrates how the test environment triggers events and how the SDK handles them before transmission:

The SDK packages events with project-specific IDs and session metadata before sending them to the ingestion endpoint.
Sources: test/demo.html:132-136, packages/analytics-web/events/auto.js:1-12

API and Ingestion Testing

Backend validation is performed using shell scripts that simulate multiple concurrent users and diverse geolocation data. This allows for testing the API's schema validation and the worker's ability to handle asynchronous jobs.

Simulated Event Injection

The fire_event.sh script is the primary tool for testing the POST /event endpoint. It simulates high-concurrency scenarios by firing multiple curl requests in the background, using X-Forwarded-For headers to spoof different geographic locations.

ENDPOINT="http://localhost:3000/event"

curl -s -X POST $ENDPOINT \
  -H "Content-Type: application/json" \
  -H "X-Forwarded-For: 103.21.58.42" \
  -d '{
    "projectId": "proj_123",
    "event": "page_view",
    "timestamp": 1706000200000,
    "sessionId": "sess_ind_1",
    "context": { "url": "https://example.com/" }
  }' &

Sources: test/fire_event.sh:6-21

Data Integrity Verification

Testing the backend logic involves verifying that the eventWorker correctly enriches events and manages session state in Redis.

Component	Validation Metric	Source File
GeoIP Lookup	Presence of country, region, city, and coordinates in logs.	app/workers/eventWorker.ts
Session Tracking	TTL expiration of 300s for session keys in Redis.	app/workers/eventWorker.ts
Event Buffering	Successful batch insertion into PostgreSQL when buffer reaches 100.	app/workers/eventWorker.ts
Active Users	Correct SADD and SCARD operations on project session sets.	app/workers/eventWorker.ts

Sources: app/workers/eventWorker.ts:87-113, PROJECT_OUTLINE.md:123-142

End-to-End Processing Flow

The testing strategy covers the entire lifecycle of a data point, as visualized in the sequence below:

This flow ensures that high-volume testing via fire_event.sh correctly exercises the buffering and enrichment logic.
Sources: app/workers/eventWorker.ts:40-120, PROJECT_OUTLINE.md:144-188

Performance and Load Testing

The project includes specific configurations for monitoring system performance during tests:

• Worker Logging: The worker logs Ready, Completed, and Failed status for BullMQ jobs.
• Live User Counts: Developers can uncomment interval-based logging to monitor activeUsers in real-time during load tests.
• Buffer Monitoring: Console logs indicate when the event buffer is being flushed to the database.

Sources: app/workers/eventWorker.ts:44-48, app/workers/eventWorker.ts:162-175