Acceptance Tests

Acceptance Tests

Originally documented in Lab 9 Report. Extracted here so each concrete acceptance test is discoverable from the sidebar. Revised so every test maps to requirements that exist in the current Requirements document and to backend behaviour that is actually shipped (the earlier community/moderator references were retired alongside the corresponding requirement-doc cleanup).

The tests below collectively cover the full functional surface — onboarding/auth, mentorship lifecycle, profile management, social-feed reporting and admin resolution, cross-platform messaging, social feed, matching/privacy/capacity, scheduler-driven state transitions, milestones/tasks, past mentorships + admin DM + ban banner, mobile parity — plus profile-visibility enforcement, admin user-management reads, follow/recommendation graph, mentee cancellation + mentor early-end, mentor rating, and advanced mentor search. Each test follows the lecture format: Test Case ID, Title, Pre-conditions, sequential Test Steps, Test Data, and Expected Results.

ID	Author	Feature	Steps
AT-01	Muhammet Sami Çakmak	User Onboarding & Authentication	9
AT-02	Beratcan Doğan	Mentorship Lifecycle & Mentor Feed Publishing	10
AT-03	Övgü Su Afşar	Registration / Login / Profile Management	10
AT-04	Mehmet Bora Sarıoğlu	Social-Feed Reporting, Search, and Sharing Lifecycle	14
AT-05	İbrahim Kayan	Polymorphic Reporting, Auto-Ban, and Admin Resolution	14
AT-06	Burak Ögüt	Cross-Platform Messaging, Reminders, Notifications	14
AT-07	Amin Abu-Hilga	Non-Functional Posture (Security, API, Performance)	13
AT-08	—	Social feed post lifecycle	10
AT-09	—	Following feed near-real-time updates	6
AT-10	—	For-You feed and explore recommendations with factors	4
AT-11	—	Mentor matching with mentee privacy mask	6
AT-12	—	Mentor capacity and request gating	5
AT-13	—	Scheduler-driven auto-decline and auto-completion	8
AT-14	—	Milestone and task lifecycle with timeline auto-refresh	8
AT-15	—	Past mentorships, admin DM, and banned-state banner	8
AT-16	—	Mobile parity — feature reachability across the React Native app	8
AT-17	—	Server-side profile-visibility enforcement	7
AT-18	—	Admin user-list and report-queue reads	7
AT-19	—	Follow graph + follow-recommendation surface	6
AT-20	—	Mentee cancel-relationship and mentor early-end	7
AT-21	—	Mentor rating after relationship ends	5
AT-22	—	Advanced mentor search filter parameters	7

---

AT-01: New user onboards, configures profile, and authenticates securely

Author: Muhammet Sami Çakmak

Covers

• User registration with real name, email, and password
• Email-uniqueness enforcement
• Password strength criteria
• Email verification before account activation
• Login with email and password
• Credential verification on login
• Error displayed when invalid credentials are submitted
• Logout
• Password reset / forgot-password recovery flow
• Mentee profile creation and editing
• Mentee specifies goals, interests, and background information
• Mentor profile creation and editing
• Mentor defines mentoring goals and preferred mentee criteria
• Profile fields populated: background, goals, skills, interests
• Profile mentoring preferences
• Profile visibility control
• Profile location field

Covered requirement meaning

A new user (mentor or mentee) must be able to register, verify their email, log in, recover access through the password-reset flow, configure their full role-appropriate profile (including location and visibility), and log out securely.

Requirement IDs covered

1.1.1.1.1, 1.1.1.1.2, 1.1.1.2.1, 1.1.1.2.2, 1.2.2.1, 1.2.2.2, 1.2.2.3, 1.2.2.5, 1.2.3.1, 1.2.3.2, 1.2.3.3, 1.2.3.4, 1.2.3.5, 1.2.3.6, 1.2.3.7, 1.2.3.8

Total: 16 requirements

Test Steps — User Onboarding & Authentication

Prerequisite: The system is running, and the user has access to a valid, unregistered email address.

#	Instruction	Expectation
1	Attempt to register a new account using a real name, a new email, and a password that meets the system's strength criteria	Account is created in a pending state; a verification email is sent to the user
2	Attempt to register a second account using the exact same email address	Registration is blocked; the system enforces email uniqueness and displays an error
3	Attempt to register with a password that fails the strength criteria (e.g., too short, missing numbers)	Registration is blocked; the system displays a password strength criteria error
4	Click the verification link in the received email, navigate to the login page, and enter the valid credentials	Login is successful (credential verification passes); user is directed to the initial profile configuration
5	Attempt to log in using an incorrect password for the verified account	Login fails; the system displays an "Invalid credentials" error message
6	Navigate to the "Forgot Password" flow, request a reset link, set a new valid password via email, and log in	Password reset is successful; user can log in with the new password
7	As a Mentee, navigate to the profile configuration screen; fill out background, goals, interests, location, and visibility; save	Mentee profile is successfully created/edited with all specified fields populated correctly
8	As a Mentor, navigate to the profile configuration screen; define mentoring goals, preferred mentee criteria, background, skills, interests, mentoring preferences, location, and visibility; save	Mentor profile is successfully created/edited with all specified fields and preferences populated correctly
9	Click the "Logout" button from the main navigation menu	User session is securely terminated; the user is redirected to the login or landing page

---

AT-02: Mentor runs a complete mentorship lifecycle and publishes feed content

Author: Beratcan Doğan Feature: Mentorship Lifecycle & Mentor Feed Publishing

Description: Verifies that a mentor can run the full mentorship lifecycle (availability, request handling, scheduling, goal/task management, feedback, early termination) and publish feed content visible on their public profile to other authenticated users. "Mentor feed posts" is the actual surface — the project never built a separate blog entity; 1.2.2.4 references the mentor's published feed posts on the profile.

Requirements covered: 1.1.1.2.1, 1.1.1.2.3, 1.1.1.2.5, 1.1.1.2.7, 1.1.1.2.8, 1.1.1.2.9, 1.1.1.2.12, 1.1.1.2.14, 1.1.4.1, 1.1.4.2, 1.1.4.6, 1.1.5.1, 1.1.5.2, 1.1.5.3, 1.1.5.6, 1.1.5.7, 1.1.5.9, 1.1.7.1, 1.1.7.2, 1.1.7.5, 1.1.7.6, 1.1.7.9, 1.2.2.4

Prerequisite:

• A verified mentor account with completed profile exists.
• The mentor is logged in.
• Seeded mentee candidate data is available in the system.

Test Steps

#	Instruction	Expectation	Reqs
1	Open the mentor dashboard and define weekly availability slots.	The availability calendar accepts the entries and saves the mentor's weekly schedule successfully.	1.1.1.2.3, 1.1.4.1
2	Open the candidate mentee profile surfaced under recommendations.	The mentee's profile renders with first name and selected fields; surname and profile photo are masked under the 1.1.2.5 rule.	1.1.1.2.4
3	Accept the mentorship request and select a duration of 1, 3, or 6 months.	The request is accepted, the duration is recorded, and the mentee is notified of the acceptance.	1.1.1.2.5, 1.1.1.2.12
4	Schedule a recurring weekly meeting with the mentee using a concrete start date.	The recurring meeting is saved and a confirmation request is sent to the mentee.	1.1.1.2.7, 1.1.4.2, 1.1.4.6
5	Define a shared goal jointly with the mentee and add at least one milestone under it.	The shared goal and its milestones are saved and visible on both mentor and mentee mentorship pages.	1.1.5.6, 1.1.5.7
6	Assign a weekly task with a deadline, then review the mentee's submission and provide structured feedback.	The task is delivered to the mentee with the correct deadline, the submission is reviewed, and feedback is recorded against the task.	1.1.5.1, 1.1.5.2, 1.1.5.3
7	Open the mentorship timeline view.	Tasks, milestones, and meetings are displayed in chronological order with a current-date indicator.	1.1.5.9
8	End the mentorship early after marking the goal as reached.	The mentorship is closed, the final status is recorded, and both users are notified.	1.1.1.2.9
9	Publish a new feed post with text + at least one hashtag, then edit it.	The post is published and visible on /feed; edits are saved and reflected on the card with an edited badge.	1.1.7.1, 1.1.7.2, 1.1.7.9
10	Switch to another authenticated user, like and comment on the post, then open the mentor's public profile.	The like count and comment appear on the post; the mentor's public profile lists their published feed posts.	1.1.7.5, 1.1.7.6, 1.2.2.4

Note: Covers mentorship lifecycle (availability, requests, scheduling, goal/task/milestone management, feedback, early termination) and feed-content publishing on the mentor's public profile.

---

AT-03: User registration, login, logout, and profile management

Author: Övgü Su Afşar Feature: Authentication & Profile Management

Description: Verifies that a new user can register with valid information, log in with the created account, update profile information according to the selected role, log out successfully, and receive an error when attempting to log in with incorrect credentials.

Prerequisite: The application is running, and the user does not already have an account with the same email address.

Test Data:

• Name: Ayşe Demir
• Email: ayse.demir@test.com
• Password: ValidPass123
• Role: Mentee
• Interests: Data Science, Career Planning
• Background: Industrial Engineering student
• Location: Istanbul

#	Instruction	Expectation	Notes
1	Navigate to the registration page	The registration screen is displayed with fields for name, email, password, role, and profile-related information
2	Enter a real name, unique email, valid password, role, interests, goals, background, and location	The system accepts all valid input values without validation errors
3	Submit the registration form	The user account is created successfully, and the system stores the new user with a unique email address	Covers 1.1.1.1.1, 1.1.1.1.2
4	Navigate to the login page and log in using the registered email and password	Login is successful, and the user is redirected to the authenticated area	Covers 1.1.1.2.1
5	Open the profile page	The profile screen is displayed with the current user information	Covers 1.2.2.1
6	Edit profile fields such as bio, goals, skills, interests, visibility, and location	The system allows the user to modify the editable profile fields	Covers 1.2.2.2, 1.2.2.3, 1.2.2.5, 1.2.3.1–1.2.3.8
7	Save the updated profile information	The profile changes are stored successfully and remain visible after refresh or revisit
8	Log out from the application	The current session is terminated successfully	Covers 2.2.1
9	Attempt to log in again using the same correct credentials	Login is successful, confirming that the account remains active after logout
10	Attempt to log in using the correct email but an incorrect password	Login fails, and the system displays an invalid credentials error message	Covers 1.1.1.2.2; passwords should not be stored as plain text

---

AT-04: Social-Feed Reporting, Search, and Sharing Lifecycle

Author: Mehmet Bora Sarıoğlu Feature: Social-Feed Reporting, Hashtag Search, and Share/Repost

Description: Walks the full life of a social-feed post from a non-author viewer's perspective: discover via hashtag/keyword search, share (silent share + quote-share repost so it appears on the sharer's followers' feeds), report when abusive, and verify that the report routes to the admin queue. Replaces the empty AT-04 placeholder which previously referenced a Community/Moderator/Forum feature family that is not part of the Requirements document.

Requirements covered: 1.1.6.1, 1.1.6.4, 1.1.7.1, 1.1.7.2, 1.1.7.3, 1.1.7.4, 1.1.7.5, 1.1.7.6, 1.1.7.7, 1.1.7.8, 1.1.7.11, 1.1.7.12, 1.1.1.3.1, 1.1.1.3.2

Prerequisite:

• Two verified accounts: a mentor M (author) and a mentee E (non-author viewer).
• An admin account exists (server-side bootstrapper).
• Both M and E are logged in in separate browser contexts; E follows M so the share/repost fanout has a recipient.

Test Steps

#	Instruction	Expectation	Reqs
1	M publishes a feed post with body "Hands-on machine learning project ideas #ml #portfolio" and the hashtags ml, portfolio.	201; the post appears at the top of M's feed with two hashtag chips.	1.1.7.1, 1.1.7.2, 1.1.7.8
2	E opens /feed and finds the post via the For-You tab.	The post is ranked into For-You based on overlapping interests.	1.1.7.3
3	E opens the Following tab.	The post is also visible because E follows M.	1.1.7.4
4	E searches /feed/search?q=ml.	The post surfaces in the keyword search results.	1.1.7.7
5	E searches /feed/search?hashtag=portfolio.	The post surfaces in the hashtag search results.	1.1.7.7, 1.1.7.8
6	E likes the post and adds a comment.	Like count flips to 1 and persists on refresh; comment appears under the post with E's first name.	1.1.7.5, 1.1.7.6
7	E bookmarks the post.	The bookmark icon flips to saved; the post is listed under /feed/bookmarks.	1.1.7.12
8	E clicks "Share" on the post and confirms the silent share action.	A share record is created; share count increments by 1 on the post.	1.1.7.11
9	E clicks "Repost" and adds commentary "Saving for the weekend".	The post is reposted; on E's followers' Following feed (if any), the post surfaces with the "shared by E" attribution and commentary.	1.1.7.11
10	E opens the post's overflow menu and clicks "Report".	A modal opens with category dropdown (HARASSMENT / INAPPROPRIATE_BEHAVIOR / SPAM / MISLEADING_PROFILE / OTHER) and a description field.	1.1.6.1
11	E selects INAPPROPRIATE_BEHAVIOR, fills "manual smoke", and submits.	POST /api/reports returns 201; the active-report partial unique index now prevents E from filing a duplicate against the same post.	1.1.6.1, 1.1.6.4
12	E attempts to file an identical second report against the same post.	The second submission returns 409 with An active report already exists for this target.	1.1.6.1
13	Admin opens /api/admin/reports?status=OPEN.	The report appears in the queue with targetType=POST, denormalised targetSummary populated, and reporterFirstName=E.	1.1.1.3.1, 1.1.1.3.2
14	Admin patches the report to UNDER_REVIEW, then RESOLVED.	Each transition returns 200 with reviewedAt populated and reviewedById/reviewedByFirstName set to the admin; the partial unique index releases so E can file a fresh report against the same target if needed.	1.1.1.3.2

Note: The 47-requirement "Community Lifecycle Management" planned for the previous version targeted a Community/Forum feature family that is not part of the project requirements; the actual social-feed surface that ships covers 12 1.1.7.x requirements plus the reporting + admin trio above.

---

AT-05: End-to-End Abuse Mitigation — Polymorphic Reporting, Auto-Ban, Admin Resolution

Author: İbrahim Kayan Feature: Platform Moderation, Abuse Reporting, and Admin Oversight

Description: Verify the lifecycle of abuse mitigation as it actually ships on the platform: a reporter files a polymorphic report (USER / POST / MENTORSHIP target), the system enforces self-report and duplicate-active guards, the admin reviews and transitions the report through the state machine, and the spam-bot detector together with the cancellation-frequency auto-ban path enforce 2.2.4 and 2.2.5. Rewrites the original draft of AT-05 which assumed a Community/Moderator feature family that is not part of the Requirements document.

Requirements covered: 1.1.1.1.13, 1.1.6.1, 1.1.6.2, 1.1.6.3, 1.1.6.4, 1.1.1.3.1, 1.1.1.3.2, 1.1.1.3.3, 2.2.4, 2.2.5

Prerequisite:

• User Reporter E (mentee, verified).
• User Reportee M (mentor, verified, completed profile, available for mentorship requests).
• User Admin D (Platform Administrator, server-side bootstrapper-created).
• Spam-bot detection (#345) and cancellation-frequency auto-ban (2.2.4, threshold property app.bans.threshold=3) are wired and enabled.

Test Steps

#	Instruction	Expectation	Reqs
1	Reporter E logs in and files a USER report against Reportee M via POST /api/reports with targetType=USER, targetId=M.id, problemType=HARASSMENT, description="repeated insults in messages".	201; the report is persisted with status=OPEN.	1.1.1.1.13, 1.1.6.3, 1.1.6.4
2	Reporter E lists GET /api/reports/me.	The report from step 1 appears with reporterId=E.id; BOLA is enforced so other users' reports are not surfaced.	1.1.6.4
3	Reporter E attempts to file an identical second USER report against M.	409 with An active report already exists for this target — partial unique index enforced.	1.1.6.3, 1.1.6.4
4	Reporter E attempts to file a USER report against themselves (targetId=E.id).	400 with Users cannot report themselves.	1.1.6.3
5	A POST report by Reporter E against any feed post authored by M (targetType=POST, problemType=INAPPROPRIATE_BEHAVIOR).	201; report is persisted with status=OPEN and targetType=POST.	1.1.6.1, 1.1.6.4
6	A MENTORSHIP report by Reporter E for an ongoing mentorship between E and M (targetType=MENTORSHIP, problemType=OTHER).	201; report is persisted with status=OPEN and targetType=MENTORSHIP.	1.1.6.2, 1.1.6.4
7	Admin D opens GET /api/admin/reports?status=OPEN and confirms the three reports are queued with denormalised targetSummary (USER → "first last", POST → body excerpt, MENTORSHIP → "Mentor: X / Mentee: Y").	All three reports listed; only ADMIN role can access this endpoint (other roles get 403).	1.1.1.3.1, 1.1.1.3.2
8	Admin D patches the USER report to UNDER_REVIEW, then RESOLVED.	Each transition returns 200; reviewedAt, reviewedById, reviewedByFirstName are set on the response.	1.1.1.3.2
9	Admin D attempts to transition the RESOLVED report back to UNDER_REVIEW.	400 with Invalid status transition: RESOLVED → UNDER_REVIEW.	1.1.1.3.2
10	Admin D bans Reportee M explicitly via POST /api/admin/users/{M.id}/ban with reason="repeated harassment" and duration=72h.	200; M's profile now reflects banStatus=ACTIVE in GET /api/admin/users?banStatus=ACTIVE.	1.1.1.3.3
11	M attempts to log in while the ban is active.	Login responds with the banned-user payload; mobile/web banner explains the ban with reason and expiresAt.	1.1.1.3.3, 2.2.4
12	A separate mentee triggers the cancellation-frequency auto-ban: cancel 3 active mentorship requests (POST /api/mentorship-requests/{id}/cancel) within the configured window.	After the 3rd cancellation the system creates a Ban row with source=MENTEE_CANCELLATION and reason="Frequent mentorship request cancellations"; the auto-banned account fails the next login attempt.	2.2.4
13	A bot-style script registers 25 accounts in 5 seconds from a single IP via POST /api/auth/register.	Spam-bot detection flips the offending IP to suspected; the new accounts are flagged with is_suspected_bot=true; subsequent attempts return 429.	2.2.5
14	Admin D clears the bot flag on one false-positive via POST /api/admin/users/{id}/clear-bot-flag (per the AdminController admin escape hatch).	200; the account's is_suspected_bot flag is reset and the user can register-flow normally.	1.1.1.3.3
21	Attempt to log in again as Spammer A.	Login is blocked. The system displays: "Account permanently banned by an Administrator."

---

AT-06: Cross-Platform Real-Time Messaging, Scheduling Reminders, and Notifications

Author: Burak Ögüt Feature: Messaging, Notifications, and Scheduling Reminders

Description: Verifies that the in-app messaging system, push notification delivery, and scheduling reminder subsystems operate correctly and consistently across web and mobile. Covers mentor–mentee messaging, mentor–mentor messaging, message history pagination, file/link attachments, push notifications for new messages and recommendations, meeting reminder notifications, notification targeting (only relevant users), and the 5-second delivery performance budget.

Prerequisite:

• Mentor A has an active mentorship with Mentee X; both accounts verified.
• Mentor B exists with a complete public profile and is reachable for mentor–mentor messaging.
• A third user (Unrelated User) exists with no connection — used to verify notification targeting.
• A scheduled meeting between Mentor A and Mentee X is set up with a reminder configured (e.g., 5 minutes before).
• Expo push notification tokens are registered for Mentor A and Mentee X on their mobile devices.
• The backend messaging API is deployed and reachable at the production server.

Test Steps

#	Instruction	Expectation
1	Log in as Mentee X on mobile; remain on Home.	Mentee X receives push: "A new mentor recommendation is available for you".
2	Log in as Mentor A on mobile; start a conversation with Mentee X and send: "Welcome! Let's start with your goals."	Message sent; thread appears in Messages with correct timestamp.
3	Verify push delivery on Mentee X's device.	Push: "New message from Mentor A" within 5 seconds.
4	Mentee X opens notification and views the conversation.	Thread opens; message visible; can type and send a reply.
5	Mentee X replies: "Hello! My goal is to improve my backend development skills."	Reply appears; Mentor A receives push within 5 seconds.
6	Mentee X attaches a document (PDF or image) and sends.	Attachment uploaded and displayed; Mentor A can preview/open it.
7	Mentee X sends a message containing a URL link.	Link tappable; opens in in-app browser or device browser.
8	Scroll up to load older messages.	Paginates correctly; no crash, no duplicates; loading indicator shown.
9	Log in as Mentor A on web; open the same conversation.	All messages, the attachment, and the link sent on mobile are visible on web; timestamps and read status consistent.
10	Mentor A on mobile → Mentor B's public profile → "Send Message" → "Hi, I'd like to discuss a shared mentoring strategy."	Message sent; thread with Mentor B appears in Messages.
11	Log in as Mentor B and check push.	Push: "New message from Mentor A" within 5 seconds.
12	Log in as Unrelated User and check inbox.	No notifications related to the messages or recommendations triggered above.
13	Wait until the scheduled meeting reminder time.	Both Mentor A and Mentee X receive a meeting-reminder push. Unrelated User does not.
14	Verify all push timestamps for steps 3, 5, 11, 13.	Each within 5 seconds of its triggering event.

---

AT-07: Comprehensive Non-Functional System Validation

Author: Amin Abu-Hilga Feature: Non-functional Posture — Public Community API, Security Defenses, and Performance Under Load

Description: The system must satisfy its non-functional guarantees — defensive security (encryption, hashing, anti-abuse heuristics, regulatory compliance), the public Community API contract with rate limiting, and platform performance under concurrent and high-volume load.

Requirements covered:

• 1.2.4.1, 1.2.4.2, 1.2.4.3, 1.2.4.4, 1.2.4.5 (Community APIs, Moderation Tools, Integrations, Rate Limiting)
• 2.2.1, 2.2.2, 2.2.3 (BCrypt Hashing, HTTPS Encryption, GDPR/KVKK Compliance)
• 2.2.5, 2.2.6, 2.2.7 (Spam bots, Vote Manipulation, Ban Evasion detection)
• 2.1.1, 2.3.2, 2.3.3, 2.3.5 (24/7 Availability, Concurrent sessions, Recommendation pipeline load, High-volume content)

Prerequisite:

• A QA testing environment is deployed with dummy seed data.
• Access to database querying tools, API testing tools (e.g., Postman), and load-testing scripts (e.g., JMeter/k6).
• Test accounts exist for a standard user and a community moderator.

Test Steps

#	Category	Instruction	Expectation
1	Security	SELECT password FROM users WHERE id = 1 directly.	Returned string is a hashed value (e.g., BCrypt) — never plaintext.
2	Security	Inspect network traffic in DevTools while logging in.	All requests strictly over HTTPS.
3	Security	Settings → "Export My Data".	System generates and downloads a JSON file with all user data (GDPR/KVKK).
4	Security	Automated script registers 100 fake accounts from one IP in 10 seconds.	Spam-bot behavior detected; IP blocked; registrations rejected.
5	Security	Register a new account with an email associated with an already banned account.	Ban evasion detected; registration rejected.
6	Security	Script: 500 upvotes on a single post from new accounts within 5 seconds.	Vote manipulation flagged; artificial upvotes nullified.
7	API	Unauthenticated GET /api/communities/{id}/posts.	200 OK with JSON array.
8	API	Unauthenticated GET /api/posts/{id}/comments.	200 OK with JSON array.
9	API	Send 2,000 requests/min to public community endpoints.	Rate-limiting enforced; 429 Too Many Requests after threshold.
10	API	DELETE a post via moderation API using a scoped moderator token.	Request succeeds — third-party moderation tool integration verified.
11	Performance	Load test simulating 5,000 concurrent mentor-mentee messaging sessions.	System sustains load; latency under 2 seconds.
12	Performance	Trigger recommendation engine under the 5,000-user load.	Pipeline returns diverse mentor suggestions without crashing.
13	Performance	Script simulating 1,000 posts/second concurrent content creation.	Posts saved successfully — high-volume scalability proven.

---

AT-08: Social feed post lifecycle — create, edit, delete, like, comment, bookmark

Author: Mehmet Bora Sarıoğlu Feature: Social Feed

Description: Verifies the end-to-end lifecycle of a feed post on the web app: an author creates a post with text and hashtags, edits it, another authenticated user likes and comments, the author bookmarks a third party's post and finds it on their bookmarks page, the author deletes their own post, and a viewer-side check confirms the deletion.

Prerequisite:

• The web app is reachable and the latest backend is serving requests.
• Two verified user accounts exist (one Mentor, one Mentee) with completed profiles. Their credentials are known.
• The mentor is logged in via the production login form; the mentee logs in in a separate browser context.

Test Steps

#	Instruction	Expectation	Requirements
1	Mentor opens /feed and clicks the New post toggle.	Composer expands; body textarea and Publish button are visible.	1.1.7.1
2	Mentor enters body Kickoff reflections #mentorship #reflection and clicks Publish.	Post appears at the top of the For You list with the author's first name, body text, and two hashtag chips.	1.1.7.1, 1.1.7.2, 1.1.7.8
3	Mentor opens the post's menu and chooses Edit.	Edit modal opens with the existing body pre-filled.	1.1.7.9
4	Mentor changes body to Kickoff reflections — first week wrap #mentorship #reflection and clicks Save.	Modal closes; the card body reflects the new text and an edited badge is visible.	1.1.7.9
5	Mentee opens /feed in a separate context and locates the post.	Post is visible in the For You list with the same body and hashtags.	1.1.7.3
6	Mentee clicks the Like button on the mentor's post.	Like icon flips to the liked state; like count increments by 1 and persists on refresh.	1.1.7.5
7	Mentee clicks Comment, enters Looking forward to week two., submits.	Comment appears under the post with the mentee's first name.	1.1.7.6
8	Mentee clicks Bookmark on the same post.	Bookmark icon flips to saved state.	1.1.7.12
9	Mentee opens /feed/bookmarks.	Bookmarks page shows the mentor's post.	1.1.7.12
10	Mentor opens the post's menu and chooses Delete, confirming.	The post disappears from the mentor's view. Mentee's refresh of /feed no longer shows it; their bookmark row is empty or marked unavailable.	1.1.7.10

---

AT-09: Following feed near-real-time updates

Author: Mehmet Bora Sarıoğlu Feature: Social Feed — Following tab + STOMP fan-out

Description: Verifies that a post published by a followed user surfaces in the follower's Following feed within the 5-second non-functional budget without a manual page refresh. Covers the STOMP /topic/feed.{userId} push contract.

Prerequisite:

• Two verified user accounts A and B exist. A follows B (follow relation already established via API seed or a prior step).
• Both users are logged in concurrently in separate browser contexts.

Test Steps

#	Instruction	Expectation	Requirements
1	User A opens /feed and switches to the Following tab.	Tab activates; the Following list renders A's followee posts (or an empty-state if none yet).	1.1.7.4
2	Confirm A's STOMP client is connected (the Following tab is wired to /topic/feed.{A.id}).	The Playwright spec waits for the WebSocket upgrade response from /ws.	1.1.7.4
3	User B publishes a new feed post via POST /api/feed/posts (API-driven so the timing is deterministic).	Backend responds 201 with the new post id.	1.1.7.1
4	Record t0 = the moment B's POST returned.	Test captures Date.now() after the API call resolves.	2.3.4
5	User A's Following tab observes the post without a refresh.	The new post appears at position 1 in A's list.	2.3.4
6	Record t1 = the moment A's DOM reflects the new post.	t1 - t0 <= 5_000 ms. The SLA assertion fails the test if the budget is exceeded.	2.3.4
7	User A clicks the post to open the detail view.	Detail view renders the full body, author, hashtags, attachments.	1.1.7.1
8	Disconnect A's WebSocket (simulate network drop in the spec).	The STOMP client's reconnect timer kicks in.	n/a (resilience)
9	User B publishes a second post while A is disconnected; A's WS reconnects.	When A reconnects, the second post arrives via the next CONNECT — observed in A's list.	1.1.7.4, 2.3.4
10	User A unfollows B; B publishes a third post.	A does NOT receive the third post on the Following tab.	1.1.1.1.15

---

AT-10: Personalized For-You feed and explore recommendations with factors

Author: Mehmet Bora Sarıoğlu Feature: Recommendation system — feed + mentor discovery

Description: Verifies the personalized For-You feed and the explore mentor recommendations, including the explanation contract: every recommended mentor card carries one or more factor chips, and at least one card in the page is flagged as a diverse pick.

Prerequisite:

• A mentee account exists with declared interests and a major. The mentee is logged in.
• At least 5 mentor profiles exist with overlapping and non-overlapping interest sets so the ranker has both relevant and diverse candidates.

Test Steps

#	Instruction	Expectation	Requirements
1	Mentee opens /feed on the For You tab.	Feed loads with at least one recommended post or — if cold-start — an empty-state plus a follow-recommendation rail.	1.1.7.3, 1.1.2.8
2	Inspect the response from GET /api/feed/for-you.	Response is a paginated list ordered by ranker score; each item exposes the underlying factors array.	1.1.7.3
3	Mentee opens /explore.	The mentor grid renders ≥ 3 mentor cards.	1.1.2.1
4	Each mentor card displays at least one factor chip (e.g. shared-interest, network-proximity, popular-in-<major>).	Every visible card has a non-empty factors region.	1.1.2.4
5	At least one mentor card in the page is labeled as a diverse-pick (chip text or pill).	The diverse-pick is present and visually distinguished from default-relevance picks.	1.1.2.3
6	Mentee toggles the AI-match mode (if surfaced) and waits for the grid to re-render.	The grid replaces baseline cards with MatchCard cards that show explanation chips per mentor.	1.1.2.1, 1.1.2.4
7	Mentee enters a keyword in the explore search box and submits.	The grid filters to mentors matching the keyword; factor chips remain attached to each card.	1.1.1.1.10
8	Mentee clears the search.	Default ranked grid is restored.	1.1.1.1.10
9	Mentee clicks the Follow button on a recommendation rail card.	The card transitions to a followed state; the follow persists on refresh.	1.1.1.1.14
10	Mentee returns to the For You tab.	The newly followed user's recent posts appear higher in the For You ranking than before (or at minimum, are no longer filtered out).	1.1.7.3, 1.1.2.8

---

AT-11: Mentor matching with mentee privacy guarantees

Author: Mehmet Bora Sarıoğlu Feature: Mentorship matching + 1.1.2.5 privacy gate

Description: Verifies that when a mentor inspects a candidate mentee profile (during the recommendation or inbox flow), the mentee's surname and profile photo are hidden — only the first name is visible. Also covers the request-acceptance flow end-to-end.

Prerequisite:

• One mentor and one mentee account exist; the mentee has a surname set on their profile and has uploaded a profile photo.
• Both users are logged in in separate contexts.

Test Steps

#	Instruction	Expectation	Requirements
1	Mentee opens /explore, locates the mentor, clicks Send request, fills the message, submits.	Modal closes; the card flips to a "Sent" state.	1.1.1.1.4
2	Mentor opens /home; the mentor inbox panel shows one pending request.	The inbox row is present and labeled by the mentee's firstName only.	1.1.1.2.4
3	Mentor opens the candidate profile preview from the inbox row.	The preview panel renders the mentee's first name, declared interests, goals, and major.	1.1.1.2.4
4	Inspect the preview for the mentee's surname.	The surname is NOT present anywhere in the preview DOM.	1.1.2.5
5	Inspect the preview for the mentee's profile photo.	The photo is NOT rendered. A neutral placeholder (initial or icon) is shown instead.	1.1.2.5
6	Mentor inspects the GET /api/mentorship-requests payload for this request.	The payload's menteeLastName is null and menteeProfilePhoto is null.	1.1.2.5
7	Mentor clicks Accept and selects a 3-month duration.	The request transitions to ACCEPTED; both sides receive a REQUEST_ACCEPTED notification.	1.1.1.2.5, 1.2.1.5
8	After acceptance, mentor opens the now-active mentorship's detail page.	The mentee's full name (first + last) IS now visible — the privacy gate only applies pre-acceptance.	1.1.2.5
9	Mentor opens the mentee's avatar in the detail page.	The mentee's profile photo IS now rendered.	1.1.2.5
10	Mentor returns to the inbox panel.	The pending row is gone; only the ACTIVE mentorship is shown in the Active section.	1.1.1.2.5

---

AT-12: Mentor capacity and request gating

Author: Mehmet Bora Sarıoğlu Feature: Mentor capacity (1.1.1.2.11) + mentorship request flow

Description: Verifies that a mentor's configured maximum mentee capacity is enforced: accepting requests up to the limit succeeds, the next request beyond the limit is rejected with a clear error, and once a mentee terminates the relationship the slot frees and the mentor can accept again.

Prerequisite:

• One mentor account with maxMenteeCapacity initially set to 2. The mentor is logged in.
• Three mentee accounts exist (M1, M2, M3), each logged in in their own context.

Test Steps

#	Instruction	Expectation	Requirements
1	Mentor opens /profile, sets max mentee capacity to 1, saves.	The setting persists; a refresh shows the new value.	1.1.1.2.11
2	M1 sends a mentorship request to the mentor.	Backend accepts the request (201).	1.1.1.1.4
3	Mentor accepts M1's request with 3-month duration.	M1 becomes the mentor's active mentee; the mentorship is ACTIVE.	1.1.1.2.5
4	Mentor's currentMenteeCount is now 1 (= capacity).	Confirmed via GET /api/users/me/mentor.	1.1.1.2.11
5	M2 attempts to send a mentorship request to the mentor.	The request is rejected with HTTP 409 and a body indicating capacity is reached. The mentor's inbox does NOT show a pending row from M2.	1.1.2.7
6	M2's UI shows a clear error stating the mentor is at capacity.	Inline error or toast surfaces the message; the request modal does not silently swallow the failure.	1.1.2.7
7	Mentor increases max mentee capacity to 2, saves.	Setting persists.	1.1.1.2.11
8	M2 retries the request.	Accepted (201); mentor's inbox now shows the pending row.	1.1.1.1.4, 1.1.1.2.5
9	Mentor accepts M2; M1 then cancels their mentorship via Cancel mentorship.	M2 is ACTIVE; M1 is CANCELLED; mentor's currentMenteeCount = 1.	1.1.1.1.12
10	M3 sends a request.	Accepted (201) because a slot is free. Mentor sees the pending row in the inbox.	1.1.2.7

---

AT-13: Scheduler-driven auto-decline and auto-completion

Author: Mehmet Bora Sarıoğlu Feature: Meeting auto-decline (1.1.4.7) + mentorship auto-termination (1.1.4.10)

Description: Verifies the two scheduler-driven state transitions: a meeting that the mentee does not confirm before its deadline is auto-declined and the mentor is notified, and an active mentorship whose end date has passed is auto-completed. Uses test-support endpoints (/api/test/trigger-meeting-auto-decline, /api/test/trigger-mentorship-auto-completion) so the spec doesn't have to wait on the production cron windows.

Prerequisite:

• A mentor and mentee with an active 3-month mentorship and a shared goal already defined.
• APP_TEST_ENDPOINTS_ENABLED=true so the trigger endpoints are wired.

Test Steps

#	Instruction	Expectation	Requirements
1	Mentor schedules a one-time meeting via POST /api/mentorships/{id}/meetings with a start time 30 minutes from now and a confirmation deadline already in the past (5 minutes ago).	Meeting created in PENDING_CONFIRMATION.	1.1.4.3, 1.1.4.6
2	Confirm the meeting status via GET /api/meetings/{id}.	Status is PENDING_CONFIRMATION.	1.1.4.6
3	Trigger the auto-decline scheduler via POST /api/test/trigger-meeting-auto-decline.	Endpoint returns 200 with {processedCount, triggeredAt}.	n/a (test infra)
4	Re-read the meeting.	Status transitions to EXPIRED.	1.1.4.7
5	Mentor opens /notifications.	A new MEETING_NOT_CONFIRMED notification (or equivalent) is present pointing at this meeting.	1.1.4.7, 1.2.1.4
6	Backdate the mentorship's endDate to one minute ago via a test-support helper (or set duration appropriately at acceptance time so this naturally passes).	The mentorship row's endDate is in the past; status still ACTIVE.	1.1.4.10
7	Trigger the auto-completion scheduler via POST /api/test/trigger-mentorship-auto-completion.	Endpoint returns 200 with {completedCount}.	n/a (test infra)
8	Re-read the mentorship via GET /api/mentorships/{id}.	Status transitions to COMPLETED; terminatedAt is set; terminatedByUserId is null (system-initiated).	1.1.4.10
9	Both mentor and mentee open /notifications.	Each sees a MENTORSHIP_AUTO_COMPLETED notification (or equivalent).	1.1.4.10, 1.2.1.4
10	Mentor opens /mentorships?status=COMPLETED.	The mentorship appears under the Past tab; not under Active.	1.1.1.2.17

---

AT-14: Milestone and task lifecycle with timeline auto-refresh

Author: Mehmet Bora Sarıoğlu Feature: Goals, milestones, tasks, progress timeline

Description: Verifies the mentor-driven milestone-and-task lifecycle on the mentorship detail page: defining a shared goal unlocks milestone creation, milestones added or edited in place trigger a timeline refresh without a page reload, tasks are assigned and progressed through their states, and the progress view reflects the rolled-up state.

Prerequisite:

• An active mentorship between a mentor and mentee, no shared goal yet defined.
• Both users logged in (mentor view drives most steps).

Test Steps

#	Instruction	Expectation	Requirements
1	Mentor opens the mentorship detail page.	The "Define a shared goal" CTA card is visible; the Milestones section shows the friendly "define a shared goal first" message.	1.1.5.6
2	Mentor clicks Add goal, fills Build a portfolio project end-to-end, saves.	The goal is saved; the CTA card disappears; the Milestones section now allows adding milestones.	1.1.5.6
3	Mentor adds a milestone titled Repo scaffolded with target date in 14 days.	The new milestone card appears in the Milestones section AND a corresponding pill appears on the timeline — both without a manual page refresh.	1.1.5.7, 1.1.5.11
4	Mentor edits the milestone's target date to 21 days from now.	The timeline pill repositions immediately; the change persists on refresh.	1.1.5.12
5	Mentor creates a task with deadline in 7 days.	Task appears in the mentee's task list; an event dot is added to the timeline.	1.1.5.1, 1.1.5.11
6	Mentee submits the task with a short submission text.	Task status transitions to SUBMITTED; mentor receives a TASK_SUBMITTED notification.	1.1.5.2, 1.2.1.7
7	Mentor reviews the task with status COMPLETED and structured feedback.	Task status is COMPLETED; mentee sees the feedback.	1.1.5.3, 1.1.1.1.7
8	Trigger the reminder scheduler via POST /api/test/trigger-reminder-scheduler after creating a new task with a deadline inside the 24h window.	A TASK_DEADLINE_REMINDER notification is created for the mentee for that task.	1.1.5.8, 1.2.1.7
9	Mentor opens the progress view of the mentorship.	Aggregated counts of milestones and tasks (total + completed) match the state created above.	1.1.5.5, 1.1.1.1.7
10	Mentor opens the timeline.	Start marker, end marker, today marker, the milestone pill, and the task event dot are all present and ordered chronologically.	1.1.5.9, 1.1.5.10, 1.1.5.13

---

AT-15: Past mentorships, admin direct messaging, and banned-state banner

Author: Mehmet Bora Sarıoğlu Feature: Mentorship history (#408) + admin DM (1.1.1.3.4) + temporary ban (2.2.4)

Description: Verifies three independent product surfaces an active user encounters during the end-of-lifecycle stage: browsing past mentorships, receiving an admin DM, and seeing the banned-state banner when the system enforces a temporary ban. The temporary-ban path is exercised by the cancel-threshold behaviour at 2.2.4.

Prerequisite:

• A mentee account with at least one COMPLETED and one ACTIVE mentorship in their history.
• An admin account is logged in in a separate context for the DM step.
• The cancel-cooldown threshold is configured to a small value (app.bans.threshold=3) so the test can trigger a temporary ban deterministically.

Test Steps

#	Instruction	Expectation	Requirements
1	Mentee opens /mentorships.	The page renders with Active and Past tabs; Active is the default. The active mentorship is visible.	1.1.1.1.16, 1.1.1.2.17
2	Mentee switches to the Past tab.	The completed mentorship is visible with its end date and status badge.	1.1.1.1.16
3	Mentee clicks the past mentorship row.	Navigates to /mentorships/:id showing the completed-state detail view (no further actions besides rate).	1.1.1.1.11
4	Admin opens /admin (gated by AdminRoute).	The admin console page renders.	1.1.1.3.4
5	Admin opens the Send direct message form, enters the mentee's user id and a body, clicks Send.	Backend responds 200; admin UI shows a success toast.	1.1.1.3.4
6	Mentee opens /messages.	A conversation labeled as an ADMIN_DIRECT thread is present with the admin's message in it.	1.1.1.3.4
7	Mentee cancels 3 mentorships within the cancel-cooldown window (using fresh active mentorships seeded for this purpose) so the cancel count crosses the configured threshold.	Each cancel returns 200; after the threshold cross, the next protected request returns 403 with body.code = 'BANNED_UNTIL'.	2.2.4
8	Mentee reloads the app or attempts any further mentorship action.	The frontend's 403 interceptor dispatches auth:banned; AuthContext flips banned state; BannedStateBanner becomes visible at the top of every authenticated page.	2.2.4
9	The banner displays the ban reason and a localized expiresAt timestamp.	Both fields render non-empty; the banner stays visible across navigation within the session.	2.2.4
10	The configured ban window elapses (or the test fast-forwards via a test-support trigger). The mentee reloads.	The banner disappears; protected requests succeed again; the user can resume normal usage.	2.2.4

---

AT-16: Mobile parity — feature reachability across the React Native app

Author: Mehmet Bora Sarıoğlu Feature: Web + mobile parity (2.1.2)

Description: Verifies that the mobile React Native app delivers the same end-user-facing capabilities as the web app for the core flows: authentication, feed browse, mentor discovery, mentorship view, milestones, scheduled meetings, and notifications. Runs as a Maestro flow against a development build of the Expo app; the build must include testID props on the target screens (already landed in #573).

Prerequisite:

• Maestro CLI installed locally; an iOS Simulator or Android Emulator boots successfully.
• The mobile app is built with EXPO_PUBLIC_BACKEND_URL pointing at the test backend.
• The backend is reachable on the loopback the device uses (http://10.0.2.2:8080 on Android emulator, http://localhost:8080 on iOS simulator).
• A seeded mentee account exists with at least one active mentorship and one scheduled meeting.

Test Steps

#	Instruction	Expectation	Requirements
1	Launch the app to the login screen and fill the email field via id: login.email-input.	The input receives the value; the controlled state is in sync (no empty submission).	2.1.2, 1.2.3.5
2	Fill the password field via id: login.password-input and tap login.submit-button.	The app transitions to the authenticated home screen within 10s.	1.2.3.5
3	Tap the feed tab via id: tabs.feed.	The Feed screen renders at least one post card.	1.1.7.1, 2.1.2
4	Tap a post's like button via id: feed.post-like.${postId}.	Like state toggles.	1.1.7.5
5	Tap the explore tab and assert at least one mentor card is visible via id: explore.mentor-card.${mentorId}.	The Explore screen renders mentor cards.	1.1.2.1, 2.1.2
6	Tap the home tab. Assert the Active tab is selected and at least one mentorship card is visible.	The Home screen renders the active mentorship.	1.1.1.1.16, 2.1.2
7	Tap the active mentorship card to open the connection profile.	The connection profile screen renders the mentor's first name and the shared goal.	1.1.1.2.4, 2.1.2
8	Tap milestones.add-button (mentor view) or the milestones list (mentee view); assert at least one milestone card is reachable via id: milestones.card.${milestoneId}.	The Milestones screen renders the milestone(s).	1.1.5.7, 2.1.2
9	Navigate to the Meetings/Sessions screen; assert the seeded meeting card via id: meetings.card.${meetingId} and that its join button (meetings.upcoming-join) is present.	The Meetings screen renders the scheduled meeting.	1.1.4.5, 2.1.2
10	Tap home.notifications-button and assert at least one notification item via id: notifications.item.${notificationId}.	The Notifications screen renders received notifications.	1.2.1.4, 2.1.2

---

AT-17: Server-side profile-visibility enforcement

Feature: Profile visibility blocking + 1.1.2.5 mask

Description: Verifies that the Mentee.profileVisibility and Mentor.profileVisibility flags gate GET /api/users/{id}, mentor/mentee list endpoints, and matching results. Also re-verifies the 1.1.2.5 mask of mentee surname/photo when a mentor views the mentee.

Requirements covered: 1.1.2.5, 1.2.2.3

Prerequisite: Two mentors M1 and M2, two mentees E1 and E2 registered + verified. An admin exists. All four sample personas default to profileVisibility=true.

#	Instruction	Expectation	Reqs
1	M1 opens GET /api/users/{E1.id} (default visible).	200; firstName present, lastName=null, profilePhoto=null (1.1.2.5 mask).	1.1.2.5
2	E1 PATCH /api/users/me/mentee with {"profileVisibility": false}.	200; the mentee's row reflects profileVisibility=false.	1.2.2.3
3	M1 opens GET /api/users/{E1.id} again.	403 with Profile is private.	1.2.2.3
4	E1 opens their own profile via GET /api/users/{E1.id}.	200 with full payload — owner self-view bypasses the gate.	1.2.2.3
5	M1 PATCH /api/users/me/mentor with {"profileVisibility": false}; M2 opens GET /api/users/{M1.id}.	M2 receives 403; private mentor blocked for another mentor viewer.	1.2.2.3
6	E2 opens GET /api/users/mentors and GET /api/matching/mentors.	Private mentor M1 is absent from both list endpoints; only M2 is visible.	1.2.2.3
7	Admin opens GET /api/users/mentors.	Both M1 (private) and M2 are returned — admin bypass.	1.2.2.3

---

AT-18: Admin user-list and report-queue reads

Feature: Admin panel reads (/api/admin/users, /api/admin/reports)

Description: Validates the read side of the admin panel: paginated user list with role / banStatus / keyword filters, per-user detail with ban history, and the polymorphic-report queue with status filter and detail.

Requirements covered: 1.1.1.3.1, 1.1.1.3.2, 1.1.1.3.3

Prerequisite: 5 seeded users (1 admin + 2 mentors + 2 mentees), one of which has at least one active ban.

#	Instruction	Expectation	Reqs
1	Non-admin calls GET /api/admin/users.	403 with Access denied.	1.1.1.3.1
2	Admin calls GET /api/admin/users with no filters.	200; paginated list of all 5 users with id, firstName, lastName, email, role, banStatus, suspectedBot, createdAt.	1.1.1.3.1, 1.1.1.3.2
3	Admin filters ?role=MENTOR, ?role=MENTEE, ?role=ADMIN.	Each returns only that role; counts match seeded fixtures.	1.1.1.3.1
4	Admin filters ?banStatus=ACTIVE, ?banStatus=NONE.	Correct partition by active ban; expired/lifted bans count as NONE.	1.1.1.3.1, 1.1.1.3.3
5	Admin keyword ?q=demir.	Only users whose firstName / lastName / email match demir are returned (ILIKE).	1.1.1.3.1
6	Admin opens GET /api/admin/users/{id} for the banned user.	200 with the merged ProfileResponse + banHistory: List<BanResponse> (newest first) + suspectedBot / suspectedAt.	1.1.1.3.2, 1.1.1.3.3
7	Admin opens GET /api/admin/reports?status=OPEN (after a report was filed).	200 with the queue; each row has the denormalised targetSummary and reporterFirstName.	1.1.1.3.1, 1.1.1.3.2

---

See also:

• Acceptance Testing Strategy
• Test Data Strategy
• Test Plan & Coverage Wiki Page
• Source: Lab 9 Report