🛡️ Data Integrity Hub
Employee directory with intentional UI data corruption for data integrity testing practice.
Overview
Data Integrity Hub exposes a clean dataset of 50 employee records via API and CSV download. The web UI, however, intentionally renders corrupted versions of 3 specific records. The core practice is comparing these three data sources — API JSON, CSV file, and the rendered HTML table — and identifying the discrepancies.
This app is designed for data migration testing, ETL validation, and learning to write tests that catch subtle data corruption (wrong values, typos, missing rows).
/api/datahub
x-api-key: <your-key>
/datahub.html
50 employees (API) / 49 (UI)
Quick Start
curl https://qacloud.dev/api/datahub/employees \ -H "x-api-key: YOUR_KEY" | jq '.employees | length' # → 50 curl https://qacloud.dev/api/datahub/employees/csv \ -H "x-api-key: YOUR_KEY" -o employees.csv wc -l employees.csv # → 51 (50 rows + header)
Dataset Overview
The dataset contains 50 employees with department IDs d001–d050. Each record has the following fields:
- id — string, format
d001–d050 - name — full name string
- department — department name string
- role — job title string
- email — email address string
- active — boolean, employment status
- salary — integer, annual USD
- hire_date — ISO date string (YYYY-MM-DD)
Sample Record (Clean — from API)
{
"id": "d001",
"name": "Alice Johnson",
"department": "Engineering",
"role": "Senior Engineer",
"email": "alice.johnson@example.com",
"active": true,
"salary": 120000,
"hire_date": "2019-03-15"
}
Intentional Bugs
Three records are deliberately corrupted in the UI rendering. The API and CSV always return clean data for these records.
API vs UI Diff Summary
| ID | Name | Field | API / CSV Value | UI Value |
|---|---|---|---|---|
d005 | Emma Wilson | active | true | false |
d012 | Elizabeth Murphy | name | "Elizabeth Murphy" | "Elizabet Murphy" |
d029 | Benjamin Green | row exists | present (row 29) | absent (deleted) |
All other 47 records are identical across API, CSV, and UI.
API Reference
Returns the complete, uncorrupted employee list. Always 50 records.
{
"employees": [
{
"id": "d001",
"name": "Alice Johnson",
"department": "Engineering",
"role": "Senior Engineer",
"email": "alice.johnson@example.com",
"active": true,
"salary": 120000,
"hire_date": "2019-03-15"
},
...
]
}
Filter by department or active status using query params: ?department=Engineering ?active=true
Returns a CSV file with the header row + 50 data rows. Total line count = 51.
Response headers: Content-Type: text/csv, Content-Disposition: attachment; filename="employees.csv"
id,name,department,role,email,active,salary,hire_date d001,Alice Johnson,Engineering,Senior Engineer,alice.johnson@example.com,true,120000,2019-03-15 d002,Bob Chen,Marketing,Marketing Analyst,bob.chen@example.com,true,85000,2020-07-22 ...
This CSV is always clean — no corruptions. Use it as the reference data to diff against the UI.
Test Cases
Steps: GET /employees → check employees.length === 50. Response should include all IDs d001–d050.
Steps: Download CSV → count lines → expect 51. Verify first line is the header row.
Steps: Open the UI. Count visible rows in the employee table → expect 50, actual is 49. Verify d029 (Benjamin Green) is missing from the rendered table.
Steps: GET /employees → find d005 → verify active === true. This is the clean/correct value.
Steps: Open UI. Find Emma Wilson (d005). Check the Active/Inactive badge → it shows "Inactive" (active: false). The API says true — this is Bug 1.
Steps: GET /employees → find d012 → verify name is exactly "Elizabeth Murphy" (with 'h').
Steps: Open UI. Find employee d012. Read the displayed name → should be "Elizabeth Murphy" but displays as "Elizabet Murphy" (Bug 2).
Steps: Download CSV → check that d005 shows active=true, d012 shows "Elizabeth Murphy" (correct spelling), and d029's row exists.
QA Tasks
?department=X response count.