Milestone Review - bounswe/bounswe2026group4 GitHub Wiki

CMPE354 D6-D7 Milestone Deliverable

Project: Local History Story Map (StoryMap)
Group: 4
Repository: bounswe/bounswe2026group4
Live URL: https://storymap.page
Tech Stack: React 19 (Vite) + Django 4.2 (DRF) + React Native (Expo 54) + MySQL 8.0

Table of Contents

D6. Milestone Review

D6.1 Project Status

StoryMap is a platform where users share historical stories tied to geographic locations. The application features a map-centric interface where stories are pinned to real-world coordinates, allowing users to explore narratives across time and space. The MVP was successfully demonstrated on April 8, 2026, with all core features functional and deployed at https://storymap.page.

Decisions Made During Development

  1. Map-centric interface chosen as the core UX paradigm (per Customer Meeting 1, Feb 18). The map is the primary entry point for discovering stories.
  2. Global scope for stories -- not limited to Turkey or any specific region. Users can share stories from anywhere in the world.
  3. Guest access provides read-only browsing; registration is required for creating stories and interacting (like, comment, save).
  4. No strict pre-verification of stories. The platform uses a reporting and moderation approach similar to Google Maps, allowing community-driven content quality control.
  5. Flexible time resolution for stories: exact year, approximate year, decade, or year range -- accommodating the inherently imprecise nature of historical memory.
  6. Tech stack selection: React (Vite) for web, Django REST Framework for backend, React Native (Expo) for mobile, MySQL for data storage.
  7. Database hosting initially on Google Cloud, later migrated to a DigitalOcean VPS for cost efficiency and operational simplicity.
  8. Mobile framework switch: The mobile team switched from native development to React Native (Expo) to accelerate cross-platform development.
  9. PR review policy: All pull requests require at least 1 review approval before merge, enforced throughout the project lifecycle.

Customer Feedback Summary

Customer Meeting 1 (February 18, 2026) -- Customer: Kutay Eroglu

  • The map is a MUST -- it is the core interface element of the platform.
  • Global scope is important; users should be able to explore stories from locations they have never visited.
  • Guest users should be able to see stories in read-only mode without registration.
  • Users can post stories about places they do not currently live in (e.g., family stories, childhood memories).
  • Filtering and searching are ABSOLUTE MUST features.
  • Like/dislike, commenting, and saving stories should all be supported.
  • Time representation should be flexible: "in my childhood," decades, year ranges are all valid.
  • Notifications are not in scope for the MVP.
  • Moderation should follow a reporting-based approach (similar to Google Maps).

Customer Meeting 2 (February 25, 2026) -- Stakeholder: Utkan Gezer

  • Story location refers to the place the memory is assigned to, not merely a map pinpoint.
  • Story components include a marginal distinguishing factor (time), a social component, and the wish to share.
  • Domain-specific input design is needed for time periods, tags, and metadata.

MVP Presentation Feedback (April 8, 2026)

  • The evaluator liked the scenario and world-building approach.
  • The evaluator was satisfied with the demo overall.
  • Positive feedback on the use of childhood imagery in the demo scenario.
  • The evaluator strongly emphasized wanting a timeline feature in the final milestone.
  • Expected behavior: user should be able to see all the stories associated with a place in a timeline format.

Requirements Elicitation Questions

The team conducted structured elicitation across the following categories:

  • Vision and Scope: Primary goal of the platform (preservation, education, community building), target user demographics, geographic coverage scope.
  • User Profile Management: User roles and permissions, guest access boundaries, profile information and privacy controls, reward/gamification systems, registration flow, age restrictions.
  • Post Browsing: Default view on the main page, display formats (map vs. feed vs. timeline), search capabilities, filtering options, who can create posts, bookmark functionality, place profile pages.
  • Media Formats: Supported media types (text, image, audio, video), interaction features (like, comment, share), story metadata requirements, notification preferences, transcription support, multi-location stories.
  • Ethics and Privacy: Complaint handling procedures, user privacy controls, content verification approach, handling of contradicting stories about the same event or location.

D6.2 Deliverables

Documentation Deliverables

Deliverable Status Details
Software Requirements Specification Completed Full SRS published on the project wiki with numbered requirements covering functional and non-functional aspects
Software Design (UML Diagrams) Completed Use case, class, and sequence diagrams published on the wiki
Scenarios and Mockups Completed 4 detailed scenarios with corresponding web and mobile mockups
Project Plan, Communication Plan, RAM Completed Project planning, regular weekly meetings, milestone tracking, and responsibility assignment documentation prepared throughout the semester
API Documentation Completed Comprehensive API documentation prepared with endpoint descriptions, request/response structures, and example usages
UX Design Completed Domain-specific UX decisions documented through scenarios, mockups, and interface design artifacts for both web and mobile

Software Deliverables

Deliverable Status Details
Pre-release Software (0.1.0-alpha) Completed Deployed at https://storymap.page
User Authentication (Register/Login/Logout) Completed JWT-based authentication with token refresh on all platforms
Guest Access (Read-Only Browsing) Completed Implemented across web and mobile
Story CRUD Completed Create, read, update, delete with all metadata fields
Map View with Story Pins Completed Leaflet on web, react-native-maps on mobile
Feed View with Cards and Pagination Completed Sorting (recent) and filtering support
Story Detail Page Completed Full narrative, metadata, image attachment support, and interactions
Search and Filter Completed By title, location, and time period
Like/Comment System Completed With atomic counter updates via Django signals
Image Upload Completed For story media attachments
User Profile In Progress Basic profile functionality implemented; full privacy controls deferred
Story Deletion Completed With confirmation flow on web and mobile
Docker + Deployment Completed Docker Compose (dev + prod), Nginx reverse proxy, CD pipeline
CI/CD Pipeline Completed Backend tests, frontend lint+build, mobile typecheck+tests
Android APK Build Completed GitHub Action for automated APK generation

Evaluation of Deliverable Status and Their Impact on the Project Plan

Overall, the milestone deliverables show that the project successfully completed the core documentation and MVP software outputs required for the current phase. Foundational deliverables such as the Software Requirements Specification, UML-based software design documents, scenarios and mockups, API documentation, and UX design artifacts were completed and published in a structured manner. On the software side, the team was able to deliver the main end-to-end MVP flow, including authentication, guest browsing, story creation and display, map and feed interfaces, story interactions, deployment, and CI/CD support. This indicates that the milestone goals were largely achieved and that the project progressed in alignment with its intended MVP scope.

At the same time, the deliverable status also highlights the boundaries of the MVP and the trade-offs made during planning and implementation. Some features originally defined in the broader requirements, such as notifications, reporting and moderation, bookmarks, gamification, timeline view, geolocation radius filtering, and richer media support, were intentionally left incomplete or postponed. In most of these areas, groundwork such as data models, validation rules, or partial backend support has already been prepared, which reduces the expected implementation risk for the final milestone.

From a project planning perspective, the completion of the core MVP deliverables had a positive effect on the overall plan because it allowed the team to establish a working, deployed, and testable system before moving on to more advanced features. This reduced uncertainty for the final milestone and created a stable baseline for integration work. However, the milestone also showed that some initially envisioned features required more time and coordination than expected, especially those involving cross-platform UI work, advanced interaction flows, and additional backend endpoints. As a result, the project plan evolved toward prioritizing core user-facing functionality first and deferring non-critical or higher-complexity features to the final milestone.

In conclusion, the current deliverable status reflects a successful MVP strategy: the project achieved its essential goals, delivered the main user journey in a deployable form, and created a solid technical and documentation foundation for the remaining milestone work. The incomplete deliverables do not indicate a planning failure; rather, they reflect conscious scope control decisions made to ensure that the most critical features were completed with adequate implementation, testing, documentation, and deployment quality.

UX Design with Focus on Domain-Specific Nature

UX Design

API Documentation

API Documentation

D6.3 Requirements

This milestone focused on implementing the requirements necessary to deliver the core MVP flow of the platform. Based on the MVP scope and feature requirements mapping, the covered requirements are grouped below by functional area.

1. User Role and Core Interaction Requirements

The following guest and registered user requirements were fully covered during MVP:

  • 1.1.1.1 Unregistered users shall be able to view stories on the map interface.

  • 1.1.1.2 Unregistered users shall be able to view stories in feed format.

  • 1.1.1.3 Unregistered users shall be able to open and read full story details.

  • 1.1.1.4 Unregistered users shall be able to view story metadata.

  • 1.1.1.5 Unregistered users shall be able to search locations on the map interface.

  • 1.1.1.6 Unregistered users shall be able to filter stories based on metadata.

  • 1.1.1.7 Unregistered users shall be able to register/create an account.

  • 1.1.1.8 Unregistered users shall have read-only access and shall not be able to perform restricted actions such as like, comment, save, submit, or report stories.

  • 1.1.2.1 Registered users shall be able to log in by providing email and password and log out securely.

  • 1.1.2.2 Registered users shall be able to create and submit stories.

  • 1.1.2.3 Registered users shall be able to edit their own stories.

  • 1.1.2.4 Registered users shall be able to like stories.

  • 1.1.2.5 Registered users shall be able to comment on stories.

  • 1.1.2.10 Registered users shall be able to do everything the unregistered users can do.

The following user-related requirement was partially covered:

  • 1.1.2.7 Registered users shall be able to remove their like, comment and bookmark.
    MVP coverage includes removing likes and comments, but not bookmark removal, since saved stories/bookmarks were deferred.

  • 1.1.2.9 Registered users shall be able to manage their profile information and visibility settings.
    MVP coverage was limited to a minimal profile implementation centered on username, contribution count, submitted stories, and a limited subset of profile fields.

2. Authentication and Profile Requirements

The following authentication requirements were fully covered during MVP:

  • 1.2.1.1 The system shall require a unique email address during registration.
  • 1.2.1.3 The system shall require a unique user name during registration.
  • 1.2.1.4 The system shall require a password that meets the specified criteria during registration.
  • 1.2.1.5 The system shall require password confirmation during registration.
  • 1.2.1.6 The system shall authenticate users via email and password during log-in.
  • 1.2.1.7 The system shall allow users to log out of their account.
  • 1.2.1.8 The system shall allow users to change their password after logging in.
  • 1.2.1.10 The system shall provide meaningful error messages for failed login attempts without exposing personal data.

The following profile-related requirement was partially covered:

  • 1.2.2.1 The system shall allow users to optionally provide and update profile information.
    Within MVP, this was covered only partially, limited to bio support rather than the full profile field set.

3. Story Display and Discovery Requirements

The following map, feed, and story page requirements were fully covered during MVP:

  • 1.3.1.1 The platform shall allow users to select a specific geographic location on the map when creating a story.

  • 1.3.1.2 The system shall require users to provide a place name in addition to selecting the geographic location.

  • 1.3.1.3 The platform shall display stories on the map, each represented by a pin associated with a specific geographic coordinate.

  • 1.3.1.5 Clicking on a pin shall display a short story preview including place name, time information, and story title.

  • 1.3.1.6 The map shall support zooming and panning.

  • 1.3.1.7 The map shall allow users to open the full story page by clicking on the preview.

  • 1.3.1.8 The map shall update displayed stories based on active search queries and filters.

  • 1.3.2.1 The platform shall provide a feed view displaying stories in card format.

  • 1.3.2.2 Each story card in the feed shall include title, location, date or time period, short preview text, and media indicators.

  • 1.3.2.3 The feed shall preserve applied filters and search criteria when a user clicks on a story and returns from the story page.

  • 1.3.2.5 The feed shall support continuous scrolling or pagination.

  • 1.3.3.1 Selecting a story from the feed or map shall open a dedicated story page.

  • 1.3.3.2 The story page shall display the full written narrative.

  • 1.3.3.3 The story page shall display story metadata including location, year or approximate time period, contributor name if visible, submission date, number of likes, and comments.

The following discovery-related requirements were partially covered:

  • 1.3.2.4 The feed shall allow sorting by most recent and most popular.
    MVP supports sorting by most recent only; most popular was deferred.

  • 1.3.5.1 The platform shall allow users to search stories by story title, story narrative text, tags, and location name.
    MVP coverage includes search by story title and location name only. Search by narrative text and tags was deferred.

  • 1.3.5.2 The system shall support filtering based on time information, location, and tag/topic/theme.
    MVP supports filtering by time information and location only. Tag/topic/theme-based filtering was deferred.

  • 1.3.5.5 The system shall update map, feed, and timeline results consistently based on active search and filter criteria.
    MVP covers consistent updates for map and feed, but not for timeline, since the timeline feature was deferred.

4. Story Submission and Media Requirements

The following submission requirements were fully covered during MVP:

  • 1.4.1.1 The system shall require a minimum set of fields for story submission to support authenticity and discoverability.
  • 1.4.1.2 The system shall support flexible time resolution for stories.
  • 1.4.1.4 The system shall allow users to submit stories associated with locations different from their profile location.

The following media and lifecycle requirements were partially covered:

  • 1.4.2.1 The system shall support story media uploads including images, audio recordings, and video.
    MVP supports image uploads only. Audio and video were deferred.

  • 1.4.2.3 The system shall validate media file type and file size during upload.
    This requirement was covered for image uploads within MVP scope.

  • 1.4.2.4 The system shall associate uploaded media with the story record and preserve media metadata needed for rendering.
    This was covered only for the image-upload flow implemented in MVP.

  • 1.4.3.1 The system shall maintain a story status, including at minimum Published and Removed.
    This requirement was covered at the backend level only during MVP.

5. Non-Functional Requirements

The following non-functional requirements were fully covered during MVP:

  • 2.2.2 All forms shall provide clear validation messages for incorrect or missing inputs.
  • 2.4.1 All communication between client and server shall use HTTPS.
  • 2.4.2 User passwords shall be stored securely using hashing mechanisms.
  • 2.4.3 The system shall enforce role-based authorization for guest, registered user, and admin actions.
  • 2.5.1 The platform shall function correctly on modern web browsers (Chrome, Firefox, Edge).
  • 2.5.2 The platform shall support responsive layouts for desktop and mobile screen sizes.

The following non-functional requirements were partially covered:

  • 2.1.1 The system shall respond to common user actions within 2 seconds under normal usage conditions.

  • 2.1.2 Search and filtering operations shall return results within 2 seconds for typical data sizes.

  • 2.1.3 The system shall support at least 100 concurrent active users while maintaining the defined response time requirements.
    Performance targets were addressed on a best-effort basis during MVP, but were not treated as fully validated completed requirements.

  • 2.2.1 The platform shall provide a consistent interface across map, feed, timeline, and story pages.
    MVP covers consistency across implemented views, but not across the timeline interface, since the timeline feature was deferred.

6. Explicitly Deferred Requirements

The following requirement groups were explicitly deferred from MVP scope:

  • 1.1.2.6 Saved stories / bookmarks
  • 1.1.2.8 Reporting stories and comments
  • 1.1.2.11 Account deletion with anonymization
  • 1.1.3.1–1.1.3.7 Admin moderation functionality
  • 1.2.1.2 Email verification via 6-digit code
  • 1.2.1.9 Password reset via email
  • 1.2.2.2–1.2.3.2 Full profile privacy and public profile display features
  • 1.3.4.1–1.3.4.4 Timeline feature
  • 1.3.5.3, 1.3.5.6–1.3.5.11 Advanced filtering, filter reset behavior, and current-location radius filtering
  • 1.3.6.1–1.3.6.5 Tag creation, management, and tag-based browsing
  • 1.4.2.2 Support for combining multiple media types in a single story beyond the MVP image-only flow
  • 1.5.1.1–1.5.1.3 Reporting workflow
  • 1.6.1.1–1.6.3.2 Notifications
  • 1.7.1–1.7.2.3 Points, badges, and gamification features.

D6.4 Testing

The full test plan and coverage documentation is available on the wiki: Test Plan & Coverage.

D6.4.1 Test Plan and Strategy

Testing Philosophy

The project follows a test pyramid strategy: a broad base of unit tests for models, serializers, and utility functions; a middle layer of integration tests for API endpoints and component interactions; and targeted end-to-end validation through manual demo rehearsals. Every feature pull request must include corresponding tests.

Core Principles:

  • Isolation: Each test is independent β€” no shared mutable state between test cases. Backend tests use Django's TransactionTestCase or TestCase with per-test database rollback. Frontend and mobile tests use fresh mock adapters per test.
  • Real database for backend: Backend tests run against a real MySQL 8.0 instance (not SQLite or mocks) to catch database-specific issues (foreign key constraints, migration problems, charset handling).
  • Fast execution: Frontend tests complete in ~5.5s, mobile tests in ~5.4s. Backend uses MD5 password hasher in test settings (instead of bcrypt) for faster auth-related tests.
  • User-centric queries: Frontend and mobile tests use @testing-library with queries like getByRole, getByText, getByPlaceholderText rather than implementation-specific selectors, ensuring tests reflect real user interactions.
  • Mocked externals: API calls are intercepted via axios-mock-adapter (frontend) and Jest mocks (mobile) to isolate UI behavior from network dependencies.

What We Test Per Layer

Backend (Django REST Framework):

Layer What is tested Example
Models Field validation, constraints, defaults, string representations, relationships test_story_requires_title, test_like_unique_constraint, test_user_total_points_default_zero
Serializers Input validation, field inclusion/exclusion, nested relationships, error messages test_register_password_mismatch, test_story_serializer_includes_contributor_name
Services Business logic, point calculations, badge awarding, counter updates test_create_story_service, test_like_increments_count
Views HTTP status codes, authentication, permissions, pagination, filtering, error responses test_unauthenticated_user_cannot_create_story, test_feed_pagination, test_search_by_location
Permissions Role-based access (guest vs registered vs admin), object-level permissions (owner-only edit/delete) test_owner_can_delete_story, test_non_owner_cannot_update
Validators Custom validation functions (year range, file size, tag format) test_year_range_start_before_end

Frontend (React + Vitest):

Layer What is tested Example
Pages Full page rendering, form submission flows, API integration, routing, loading/error states test_login_submits_credentials, test_feed_shows_stories, test_submit_story_with_image
Components Rendering with various props, user interactions (click, type, select), conditional UI test_like_button_toggles, test_comment_section_posts_comment, test_map_renders_markers
UI Primitives Rendering variants, accessibility, prop handling test_loading_skeleton_renders, test_error_state_shows_retry
Services API call construction, token management, interceptor behavior, error handling test_api_refreshes_expired_token, test_story_service_creates_story
Hooks/Context State management, side effects, context propagation test_auth_context_provides_user, test_filter_state_resets_page

Mobile (React Native + Jest):

Layer What is tested Example
Screens Screen rendering, data loading, user interactions, navigation triggers test_feed_screen_loads_stories, test_map_screen_renders_markers, test_story_screen_shows_comments
Navigation Role-based routing (guest/user/admin), back stack management, deep linking test_guest_sees_auth_screen, test_user_sees_feed, test_back_navigation
Auth Login/register flows, token persistence, session handling, auto-refresh test_login_stores_tokens, test_logout_clears_session
Services/Data API calls, data mapping, repository pattern, remote data sources test_feed_service_fetches_stories, test_story_mapper_transforms_api_response
Shared Components Reusable UI components, filter interactions, search behavior test_filter_panel_applies_filters, test_search_input_debounces

CI Pipeline Integration

Tests are enforced via GitHub Actions (.github/workflows/ci.yml) with three parallel jobs on every push to main and on pull requests:

Job Runner Steps Dependencies
backend-tests Ubuntu, Python 3.12 pytest -v MySQL 8.0 service container
frontend-checks Ubuntu, Node 20 npm run lint, npm run build β€”
mobile-checks Ubuntu, Node 20 npm run typecheck, npm test -- --runInBand β€”

Test Configuration

Platform Config File Key Settings
Backend backend/pytest.ini DJANGO_SETTINGS_MODULE=config.settings.test, pattern: tests/test_*.py
Backend config/settings/test.py DEBUG=False, MD5PasswordHasher, in-memory email backend
Frontend frontend/vite.config.js (inline) Environment: jsdom, globals: true, CSS: enabled, setup: src/test/setup.js
Mobile mobile/package.json Preset: jest-expo, setup: jest.setup.ts

Shared backend test fixtures are defined in backend/conftest.py: user, second_user, admin_user, and story β€” providing consistent test data across all apps.

D6.4.2 Test Execution Reports

Generated Unit Test Reports are here

Backend Test Breakdown (569 tests across 29 files)

App Test Files Test Count What is Covered
users test_models, test_permissions, test_serializers, test_services, test_views 161 User creation, email validation, password hashing, JWT auth (register/login/logout), token refresh, profile CRUD, privacy controls, role-based permissions
stories test_models, test_serializers, test_services, test_views 171 Story CRUD, field validation (time_type, coordinates, required fields), feed endpoint (sorting, filtering, pagination), map endpoint (bounding box), search endpoint, story deletion with cascade
interactions test_models, test_serializers, test_services, test_views 98 Comment creation/deletion, like/unlike toggle, saved stories, unique constraints (no duplicate likes), Django signal-based counter sync (like_count, save_count), anonymous comment handling on user deletion
media test_models, test_serializers, test_services, test_views 37 Image upload, file type validation (JPEG/PNG), file size tracking, media association with stories, display ordering
common test_exceptions, test_permissions, test_validators 28 Custom exception classes, permission classes (IsOwnerOrReadOnly, IsAdminUser), year range validator, file size validator
gamification test_models, test_services, test_views 22 Point transactions (award/deduct), badge criteria (stories_published, points_total), badge awarding, immutable audit log
tags test_models, test_views 22 Tag creation, lowercase-dash format validation, story-tag M2M (max 3), denormalized story_count
notifications test_models, test_views 15 Notification types (new_comment, new_like, etc.), read/unread status, per-type preferences
reports test_models, test_views 15 Report creation, reason enum, status transitions, duplicate prevention (unique constraint per user+story)

Commands:

# Run backend tests (requires Docker for MySQL)
docker compose run --rm web pytest -v

# Run with coverage
docker compose run --rm web pytest -v --cov=apps --cov-report=html

Frontend Test Breakdown (363 tests across 33 files)

Category Test Files Count What is Covered
Pages FeedPage(20), LoginPage(18), RegisterPage(23), SubmitStoryPage(16), StoryDetailPage(37), ProfilePage(9), MapPage(6), NotFoundPage(5) 134 Full page rendering, form validation (email, password strength, required fields), API integration (success/error flows), navigation/routing, loading/error/empty states, authenticated vs guest behavior
Components CommentSection(25), StoryCard(22), SearchFilter(11), FilterPanel(10), AppLayout(10), LikeButton(9), SearchBar(9), MapView(9), MapPicker(6), ActiveFilters(13), StoryDetailMap(4), StoryPopup(3), ProtectedRoute(3) 134 Component rendering, user interactions (click/type/submit), conditional rendering, prop handling, accessibility, responsive behavior
UI Primitives EmptyState(8), ErrorState(8), Toaster(7), LoadingSpinner(6), LoadingSkeleton(5) 34 Variant rendering, message customization, retry callbacks, accessibility
Services storyService(19), api(9), tokenStore(8), authService(6) 42 API call construction, request/response handling, token storage/retrieval, interceptor-based token refresh, error propagation
Context/Hooks useFilterState(9), AuthContext(8), useAuth(2) 19 Auth state management, filter state transitions, page reset on filter change, context propagation

Commands:

# Run frontend tests
cd frontend && npm run test:run

# Run with UI (watch mode)
cd frontend && npm run test

Mobile Test Breakdown (111 tests across 28 files)

Category Test Files Count What is Covered
Screens StoryScreen(15), FeedScreen(13), MapScreen(8), ProfileScreen(5), SubmissionScreen(3) 44 Screen rendering, data loading from API, user interactions, navigation triggers, loading/error states
Navigation RootNavigator(9), linking(2) 11 Role-based routing (guest β†’ auth screen, user β†’ feed/map, admin β†’ moderation), back stack management, Android back button, deep link configuration
Auth AuthContext(9), AuthFormCard(2) 11 Login/register flows, token persistence in secure storage, session restoration, auto-refresh on 401, logout cleanup
Services/Data storyService(4), userService(3), StoryRepository(3), storyMappers(2), feedRemoteSource(2), feedService(1), MapRepository(1), client(1) 17 API calls, data transformation (API β†’ domain models), repository pattern, error handling
Shared UI FilterPanel(4), EmptyState(3), ErrorState(3), LoadingSkeleton(3), NotFoundPage(3), FilterChips(2), SearchInput(2), Toast(2), Loader(2) 24 Component rendering, filter application/removal, search debounce, state display variants
Hooks useDebounce(1) 1 Timer-based debounce behavior

Commands:

# Run mobile tests
cd mobile && npm test

# Run specific test file
cd mobile && npm test -- StoryScreen

D6.4.3 Impact Analysis

Coverage

The test suite covers 1,043 test functions across 90 test files and ~13,160 lines of test code, spanning all three platforms.

Backend Coverage (569 tests):

  • All 8 Django apps have dedicated test files covering every architectural layer (models β†’ serializers β†’ services β†’ views)
  • All 20 active API endpoints are tested for success cases, validation errors, permission checks, and edge cases
  • Database constraints (unique, foreign key, cascade delete) are explicitly verified
  • Django signals for counter synchronization (like_count, save_count) are tested for consistency
  • Custom permission classes tested for all role combinations (guest, registered, owner, admin)

Frontend Coverage (363 tests):

  • All 8 pages have dedicated test suites covering rendering, form flows, and API integration
  • All 13 interactive components tested for user interactions and conditional rendering
  • All 5 UI primitives tested for variant rendering and accessibility
  • All 4 API services tested for request construction and error handling
  • Token refresh interceptor tested for automatic retry on 401 responses
  • Filter state management tested for URL synchronization and page reset behavior

Mobile Coverage (111 tests):

  • All 5 main screens tested for rendering and data loading
  • Role-based navigation tested for all 3 user roles (guest, registered, admin)
  • Auth flow tested end-to-end: login β†’ token storage β†’ session restore β†’ refresh β†’ logout
  • Repository pattern tested at data, mapper, and service layers
  • Shared UI components and filter system tested for consistent behavior across map and feed

Bugs Detected Through Testing

  1. Token refresh race condition (#344, #348) β€” Both frontend and mobile had issues where expired JWT access tokens caused automatic logouts instead of silently refreshing. The frontend interceptor was not correctly queuing concurrent requests during refresh, and mobile was not persisting the new access token after refresh. Detected through integration testing of the auth flow and user reports during demo rehearsal. Fix: Added Axios response interceptor that catches 401 errors, calls /auth/token/refresh/, retries the original request with the new token, and queues concurrent requests to avoid duplicate refresh calls.

  2. CORS misconfiguration (#148) β€” Frontend API calls were blocked by the browser with "No 'Access-Control-Allow-Origin' header" errors. The Django backend had no CORS configuration. Caught immediately during the first frontend-backend integration test. Fix: Added django-cors-headers middleware with CORS_ALLOW_ALL_ORIGINS = True for development.

  3. Media file 404s (#298) β€” Uploaded story images returned HTTP 404 in the development environment. Django's MEDIA_URL and MEDIA_ROOT were configured, but the URL patterns for serving media files in development were missing. Discovered through the story detail page tests expecting images to render. Fix: Added static(settings.MEDIA_URL, document_root=settings.MEDIA_ROOT) to URL patterns when DEBUG=True.

  4. Map pin display limit (#346) β€” The map view was silently capping the number of visible story pins due to a low default limit in the API query. With only a few pins showing, the map appeared empty for locations with many stories. Discovered during user acceptance testing with populated data. Fix: Increased the maximum number of returned map markers to 100.

  5. Navigation conflicts (#247, #338) β€” The FeedPage component had its own navigation header that overlapped with the AppLayout navbar, causing duplicate controls and broken routing on small viewports. Caught through AppLayout component tests and manual mobile viewport testing. Fix: Removed the duplicate navigation from FeedPage and consolidated all navigation into AppLayout.

  6. Missing username in story endpoints (#270) β€” Story API responses did not include the contributor's username, forcing the frontend to make separate API calls for each story to show the author name. Discovered when frontend StoryCard tests expected a contributor_name field. Fix: Added contributor_name as a read-only field to StorySerializer.

  7. Mobile filter panel bugs (#329) β€” Multiple filter-related UX issues: year input accepted invalid values, filter state was shared between map and feed views (filtering on map also filtered the feed), and resetting filters didn't clear the search text. Discovered through FilterPanel and SearchInput tests. Fix: Separated filter state per scope (map vs feed), added year input validation, and connected reset to clear all state.

  8. Mobile map pin drops (#302) β€” Story pins on the mobile map were not rendering because the marker component was receiving coordinates as strings instead of numbers. Caught through MapScreen tests. Fix: Added numeric type coercion in the map data mapper.

D6.5 Planning and Team Process

Description

The team of 8 members was organized into three sub-teams from the start of the semester and operated under a shared set of documented processes throughout the project.

The process was centered around:

  • GitHub issues and pull requests as the main technical coordination mechanism β€” all tasks were tracked as issues, all changes went through PRs with at least 1 required approval before merge, and no direct pushes to main were permitted
  • Google Meets for weekly Monday evening full-team meetings (9 held across the semester), covering progress updates, blockers, and planning for the upcoming period
  • Sub-team meetings held as needed for detailed technical coordination within frontend, backend, and mobile groups (7 sub-team meetings documented)
  • Wiki-based documentation for planning, meeting notes, customer feedback, scenarios, and milestone artifacts β€” kept current throughout the semester
  • Structured branching and commit conventions (feat/, fix/, refactor/, docs/ prefixes; type: description commit format) enforced across all sub-teams

Planning was organized as follows:

  • The MVP was planned in a 3-week sprint (March 15 – April 6) with explicit in-scope / out-of-scope decisions, a risk register, and a Definition of Done.
  • An internal Core Implementation Complete gate was set for April 2 to confirm all core features were working before the polish and deployment phase.
  • The final milestone was planned in a 5-week sprint with weekly gates (FM1–FM5) covering all remaining features.
  • One process adjustment was made during the semester: Oğuz Semih ArΔ±k transferred from the backend team to the mobile team due to imbalanced workloads.
  • Minor scope changes happened in the Milestone plans which were all documented in the related wiki pages.

Evaluation

Version Control

Every change followed the same path: GitHub issue β†’ named branch (feat/, fix/) β†’ PR with at least 1 approval β†’ merge, with direct pushes to main blocked. The review policy paid off in concrete terms β€” it caught allowed us to catch bugs early and fix them in their individual branches before ever being merged into main. Commit conventions (type: description) kept the history readable across three platforms.

Project Management

Running web, mobile, and backend in parallel required explicit planning. The MVP was structured as a 3-week sprint with an internal April 2 milestone (Core Implementation Complete) to confirm all end-to-end flows worked before the deployment phase began. Deferred features were listed by name with documented rationale so scope stayed stable and prevented feature creep. This allowed us to finish our MVP implementation earlier than the due date and left time for extensive testing and polishing. Our project was deployed on April 3rd, almost 5 days before the due date. Nine full-team and seven sub-team meetings were held across the semester, all documented on the wiki. Ownership was tracked via the Responsibility Assignment Matrix.

Design Tools

UML artifacts (4 use-case diagrams, 1 class diagram, 8 per-member sequence diagrams) were authored in PlantUML and committed to the wiki, keeping them version-controlled alongside the code. The same scenarios written for requirements elicitation drove the mockups β€” and one of them (Eski Γ‡Δ±nar ParkΔ±) became the narrative spine of the MVP demo, giving the design artifacts continuity all the way through to presentation day and making our implementation phase focused and easy.

Reflection

What worked well:

  • The PR review policy and named scope boundary kept quality high and the final sprint focused β€” buffer days were spent on polish, not on firefighting integration failures.
  • The CI/CD pipeline made deployment automatic on merge to main; Docker environment parity meant production behavior matched local development throughout.
  • Sub-team ownership with documented API contracts let frontend, backend, and mobile progress in parallel without waiting on each other.

Areas for improvement:

  • Most implementation compressed into the last two weeks of the sprint; workload should be distributed earlier, and team members should flag overloaded tasks sooner so others can step in before it compounds.
  • Frontend unit tests ran locally but were not enforced in CI during the MVP phase. This is a committed fix for the final milestone, not a deferred one.

Links to Screenshots and Documents

D7. Individual Contributions

# Name Subgroup Contribution Link
1 Oguz Semih Arik Mobile Individual Contribution MVP
2 Omer Faruk Celik Frontend Individual Contribution MVP
3 Sezin Doğan Frontend Individual Contribution MVP
4 Ahmet Cagdas Girit Backend Individual Contribution MVP
5 Mert Eren Kaplan Mobile Individual Contribution MVP
6 Aysu Keskin Backend, Dev-Ops Individual Contribution MVP
7 Kemal Mahmutogullari Dev-Ops, Backend Individual Contributions MVP
8 Osman Yusuf Tosun Mobile Individual Contribution MVP