Using Seeded Dummy Data for Testing
Using Seeded Dummy Data for Testing
Overview
The SafeRide backend includes comprehensive seed data designed to support a wide variety of testing scenarios. This tutorial explains how to use this data effectively when testing the UI or making API requests via Postman.
Quick Start
1. Seed the Database
Run the following command to populate your development database with test data:
cd backend
make seed
This will a special command rails db:seed:replant, which regenerates all the seed data from scratch, ensuring a consistent testing environment each time, so there should be no need to reset the database first.
Note: Nevertheless, if you need a fresh start:
docker compose exec api bundle exec rails db:reset
This runs db:drop, db:create, db:migrate, and db:seed in sequence.
2. Use Test Credentials
All test accounts use the same password:
Password: password123
Test Account Reference
Single Role Accounts
| Role | Use Case | |
|---|---|---|
admin@example.com |
Admin | Admin panel testing, dispute management |
passenger@example.com |
Passenger | Basic passenger flows |
driver@example.com |
Driver | Basic driver flows |
dispatcher@example.com |
Dispatcher | Dispatch console, ride assignment |
host@example.com |
Host | Venue management |
Multi-Role Accounts
| Roles | Use Case | |
|---|---|---|
passenger_driver@example.com |
Passenger, Driver | Role switching between passenger and driver |
passenger_driver_dispatcher@example.com |
Passenger, Driver, Dispatcher | Complex role switching scenarios |
passenger_driver_dispatcher_admin@example.com |
All roles | Full access testing |
Test Passengers (10 accounts)
Emails: passenger1@example.com through passenger10@example.com
Each passenger has:
- Passenger preferences (preferred driver sex: male/female/any)
- 1-3 saved addresses
- Notification preferences
Test Drivers (10 accounts)
Emails: driver1@example.com through driver10@example.com
| Driver | Availability | Shift | Special Conditions |
|---|---|---|---|
| driver1@example.com | available | day | - |
| driver2@example.com | available | day | - |
| driver3@example.com | available | day | - |
| driver4@example.com | offline | day | - |
| driver5@example.com | offline | day | - |
| driver6@example.com | busy | night | Night shift (18:00-06:00) |
| driver7@example.com | busy | night | Night shift (18:00-06:00) |
| driver8@example.com | available | day | Stale location (30+ min old) |
| driver9@example.com | available | day | No location data |
| driver10@example.com | available | day | - |
Driver sex distribution: Mix of male and female for passenger preference matching tests.
Test Dispatchers (3 accounts)
Emails: dispatcher1@example.com through dispatcher3@example.com
Seeded Data Summary
After running seeds, you’ll have:
| Data Type | Count | Description |
|---|---|---|
| Accounts | 31 | Various roles and configurations |
| Addresses | 32 | Venues + residential (Frederick area) |
| Vehicles | 10 | Mix of automatic/manual transmission |
| Driver Profiles | 10 | Various availability states |
| Rides | 45 | All statuses represented |
| Payments | 28+ | Various statuses and methods |
| Donations | 14 | Standalone and ride-associated |
| Disputes | 14 | All dispute statuses |
| Feedback | ~15 | Ratings 1-5 with comments |
| Notifications | 90+ | Various types and channels |
Testing Scenarios
Ride Lifecycle Testing
The seed data includes rides in every status:
| Status | Count | Description |
|---|---|---|
requested |
5 | Awaiting driver assignment |
assigned |
8 | Driver accepted (includes 3 dispatcher-assigned) |
in_progress |
5 | Currently active rides |
completed |
22 | Finished rides (includes 2 free rides) |
canceled |
5 | Canceled rides |
Example: Test ride assignment flow
- Login as
dispatcher@example.com - View rides with status
requested - Assign an available driver
- Verify status changes to
assigned
Payment Testing
| Payment Status | Description |
|---|---|
pending |
Awaiting processing |
succeeded |
Payment completed |
failed |
Payment failed |
requires_action |
3DS or additional auth needed |
canceled |
Payment canceled |
Payment methods seeded: Card and cash
Dispute Testing
| Status | Count | Use Case |
|---|---|---|
open |
3 | New disputes awaiting review |
investigating |
3 | Assigned to admin |
resolved |
5 | Completed with resolution |
closed |
2 | Closed without action |
escalated |
1 | Requires management review |
Dispute reasons seeded: fare_dispute, driver_behavior, safety_concern, route_issue, vehicle_condition
Notification Testing
Notifications are created for each account with:
- Kinds: ride_assigned, ride_started, ride_completed, payment_received, dispute_opened, dispute_resolved
- Channels: in_app, email, sms, push
- Delivery statuses: pending, sent, delivered, failed
- Read states: Mix of read and unread
Driver Matching Testing
Test passenger preference matching:
- Login as a passenger with a specific
preferred_driver_sex - Request a ride
- Verify only matching drivers are suggested
Available combinations:
- Passengers with male, female, or any preference
- Drivers of male or female sex
Postman Setup Guide
Step 1: Authentication
Request:
POST /api/v1/login
Content-Type: application/json
{
"email": "passenger1@example.com",
"password": "password123"
}
Response:
{
"data": {
"attributes": {
"token": "eyJhbGciOiJIUzI1NiJ9...",
"account": {
"id": 1,
"email": "passenger1@example.com",
"roles": ["passenger"],
"active_role": "passenger"
}
}
}
}
Step 2: Set Authorization Header
For subsequent requests, add:
Authorization: Bearer <token>
In Postman, you can set this in the Authorization tab or use environment variables.
Step 3: Example API Calls
Get Available Drivers
GET /api/v1/drivers/available
Authorization: Bearer <token>
Returns drivers with availability_status: 'available' and recent location updates.
List Rides by Status
GET /api/v1/rides?status=requested
Authorization: Bearer <token>
Get Ride Details with Relationships
GET /api/v1/rides/:id
Authorization: Bearer <token>
Returns ride with associated passenger, driver, pickup_address, dropoff_address, payment, and feedback.
List Disputes
GET /api/v1/disputes
Authorization: Bearer <token>
Get Notifications
GET /api/v1/notifications
Authorization: Bearer <token>
Address Reference
Pickup Locations (Venues)
These are bars and restaurants in Frederick, MD where rides typically originate:
| Venue | Address |
|---|---|
| Black Hog BBQ | 221 N East St, Frederick, MD 21701 |
| Bushwaller’s Irish Pub | 209 N Market St, Frederick, MD 21701 |
| Belles’ Sports Bar and Grill | 1202 E Patrick St, Frederick, MD 21701 |
| The Greene Turtle Sports Bar & Grille | 5225 Westview Dr #50, Frederick, MD 21703 |
Dropoff Locations (Residential)
Frederick City:
- 113 Pennsylvania Ave, Frederick, MD 21701
- 1510 Havilland Pl, Frederick, MD 21702
- 326 Ensemble Way, Frederick, MD 21701
Frederick County:
- 8803 Biggs Ford Rd, Walkersville, MD 21793
- 2240 Monument Rd, Myersville, MD 21773
- 7002 Springdale Ln, Middletown, MD 21769
Neighboring Counties (for cross-county ride testing):
- 418 London Ct, Westminster, MD 21157 (Carroll County)
- 4718 Bounty Ct, Ellicott City, MD 21043 (Howard County)
- 8709 Hayshed Ln #22, Columbia, MD 21045 (Howard County)
Global Settings
The seeds include application configuration values:
| Setting | Value | Description |
|---|---|---|
default_fare_per_mile |
250 | Cents per mile |
minimum_fare_cents |
500 | $5.00 minimum |
maximum_fare_cents |
10000 | $100.00 maximum |
driver_payout_percentage |
80 | 80% to driver |
ride_request_timeout_minutes |
5 | Request expiry |
max_pickup_distance_miles |
25 | Maximum pickup distance |
support_email |
support@saferide.org | Support contact |
support_phone |
+1-800-SAFERIDE | Support phone |
Testing Tips
1. Test Different User Perspectives
Login as different roles to test the same feature from multiple perspectives:
- Passenger view: Request ride, track driver, provide feedback
- Driver view: Accept ride, navigate, complete ride
- Dispatcher view: Assign drivers, manage fleet, resolve issues
- Admin view: Handle disputes, view analytics, manage users
2. Test Edge Cases
The seed data includes edge cases:
- Free rides:
fare_cents: 0 - Drivers without location: Test fallback behavior
- Stale driver locations: Test location freshness validation
- Multi-stop rides: Rides with intermediate stops
3. Test Pagination
With 45 rides, 14 disputes, and 90+ notifications, you can test:
GET /api/v1/rides?page=1&per_page=10
GET /api/v1/rides?page=2&per_page=10
4. Test Filtering
GET /api/v1/rides?status=completed
GET /api/v1/rides?passenger_id=5
GET /api/v1/disputes?status=open
GET /api/v1/notifications?read=false
5. Test Date Ranges
Completed rides span the last 30 days:
GET /api/v1/rides?from_date=2025-11-01&to_date=2025-11-24
Troubleshooting
Seeds fail with geocoding errors
The seeds use GeocodingService to fetch coordinates. Ensure:
- Google Maps API key is configured
- API key has Geocoding API enabled
- You have sufficient API quota
Duplicate key errors
If you’ve run seeds before:
docker compose exec api bundle exec rails db:reset
Missing associations
Some data has intentional gaps for testing:
- Not all rides have feedback (tests “no feedback” state)
- Some canceled rides have no driver (tests “canceled before assignment”)
Extending the Seeds
To add custom test data, edit db/seeds.rb. The file is well-organized with sections:
- Accounts
- Addresses
- Vehicles
- Driver Profiles
- Passenger Preferences
- Account Addresses
- Notification Preferences
- Rides
- Ride Stops
- Payments
- Donations
- Disputes
- Feedback
- Notifications
- Ride Histories
- Driver Locations
- Global Settings
Related Documentation
- How to Get an Address ID - Creating addresses for rides
- API Documentation - Full API reference
- Authentication Flow - Login and JWT tokens
- WebSocket Client Guide - Real-time updates
Need Help?
If you have questions or run into issues:
- Check the API Documentation
- Review the Swagger specifications
- Open an issue on GitHub