Test Data Strategy

Test Data Strategy

Originally documented in Lab 9 Report. Extracted here so the strategy is discoverable from the sidebar.

Our data strategy is based on synthetic and scenario-based test data. Because the system handles personal profile information, we will not use real user data; instead, we generate realistic mentor, mentee, community, and messaging data that reflects the two stakeholder personas the project targets — campus students and neighborhood professionals or retirees. The strategy extends the existing seed infrastructure in our repository (seed.sql and scripts/seed_mentors.py) rather than replacing it, and is organized into four layers: bulk synthetic generation, scenario fixtures, validation, and reproducibility.

1. Bulk Synthetic Generation

For high-volume data we will introduce a scripts/test-data/ package containing per-domain generators driven by a shared taxonomy.json (skills, majors, Istanbul districts and Anatolian cities, community topics) and a personas.json archetype file. The generators rely on the following tools, chosen so that data feels authentic rather than mechanically synthesized:

• Faker (Python, tr_TR locale) for names, emails, lorem text, and dates that match the Turkish character of the project and stay consistent with the style of the existing seed.sql.
• factory_boy for declarative factories with relationships, so a single MentorshipFactory can produce a coherent Mentor + Mentee + MentorshipRequest graph in one call.
• ESCO (European Skills, Competences, Qualifications and Occupations) REST API for standardized skill and occupation labels, reused from our Use of Standards page so that interests, expertise, and preferredMenteeSkills are anchored in a recognized taxonomy.
• Wikidata SPARQL for real Turkish university and tech-company names used in the affiliation field.
• NetworkX to generate community follower graphs and vote graphs with realistic power-law and preferential-attachment distributions, which we then sample to produce (user, post) and (user, comment) vote edges.
• Stack Exchange Data Dump (CC-BY-SA 4.0) as the source for community posts and threaded comments. We map Stack Exchange tags to our community topics (e.g. tag java → "Backend" community, tag react → "Frontend") and preserve native threading. This avoids the Reddit data-licensing constraints introduced in 2023.
• Wikipedia article extracts (wikipedia Python package) for blog post seed text.
• Templated conversation arcs for messaging — eight predefined arcs (introduction, weekly check-in, task feedback, schedule discussion, milestone celebration, blocker, off-topic chat, end-of-mentorship) slot-filled with Faker for fully deterministic generation. For higher-fidelity demo data we may use the Anthropic Claude Haiku API to generate roughly one hundred mentor–mentee dialogues conditioned on persona pairs and an arc, at a cost below one US dollar.
• bcrypt for password hashing prior to bulk SQL insertion, matching the format already used by seed.sql.

2. Scenario-Based Fixtures

In addition to bulk data, we hand-craft a small set of named test accounts that drive acceptance-test scenarios: a verified mentor, a verified mentee, an unverified user, a mentor at full capacity, a mentee with an active mentorship, an admin, a banned mentee, and a mentor with published blog posts. We also seed realistic recurring weekly availability entries for the scheduling features and a small set of curated communities (Backend, Frontend, ML, Mobile, Internship-Hunt, Career-Switch) populated with hand-picked posts so that the demo flow is predictable. These fixtures live as overlays on top of the bulk layer, following the pattern already established by scripts/seed_mentors.py.

3. Validation

To validate that the test data reflects realistic usage patterns we will:

1. Implement an audit script (scripts/test-data/audit.py) that enforces hard distribution thresholds — for example, at least five mentors at full capacity, ten mentees with an active mentorship, three expired or auto-terminated mentorships, fifty pending requests, one hundred posts in each curated community, and one banned account. The audit fails CI if any threshold drops.
2. Conduct a manual stakeholder walkthrough on the seeded staging environment before each milestone, confirming that profiles, capacities, interests, schedules, community discussions, and mentor–mentee conversations are coherent and that the system's matching and request results are meaningful from a user perspective. This continues the practice already used successfully for the Lab 7 MVP demo.
3. Produce distribution histograms (interests, majors, capacity utilization, mentorship state, vote counts, community sizes) as part of the audit output and flag drift greater than ten percent against target distributions.

4. Reproducibility

To keep test runs deterministic and cheap, the bulk generators use a fixed Faker.seed(42) in CI and a different seed in staging so that manual QA sees varied data. Generators are idempotent (INSERT ... ON CONFLICT DO NOTHING) so they can be re-run safely. After seeding, a pg_dump snapshot is committed as seed-snapshot.sql; CI restores from this snapshot in seconds rather than regenerating from scratch on each run.

---

See also:

• Acceptance Testing Strategy — overall approach and coverage goals
• Acceptance Tests — the seven concrete test cases that consume this data