[testing] Adopt Compose Screenshot Testing Workflow Across Modules

[wax911]

AniTrend Issue Guidelines

Before opening a new issue, please take a moment to review our community guidelines to make the contribution process easy and effective for everyone involved.

You may find an answer in issues:
https://github.com/AniTrend/anitrend-v2/issues?q=is%3Aissue+is%3Aclosed

Enhancement Information

Introduce a platform-level screenshot testing workflow using Android Studio Compose Screenshot Testing:
https://developer.android.com/studio/preview/compose-screenshot-testing

This is not a product feature request. It is a platform/test-infrastructure initiative to improve visual consistency and design iteration quality across modules.

Primary goals:

• Add and standardize screenshotTest usage in the project workflow.
• Keep screenshot artifacts in a predictable folder structure that can be consumed by design-focused skills (for example product-designer) and human visual review.
• Enable iterative UI design validation until expected visual quality is achieved.
• Roll out coverage to most feature/* modules and shared common/* UI modules.

Solution Information

Proposed implementation outline:

1. Project/platform setup

• Define baseline conventions for screenshot tests, naming, and directory layout.
• Add module-level setup instructions for enabling screenshot testing in Compose modules.
• Document verification commands and CI/local expectations.

2. Artifact conventions

• Standardize a screenshot output folder strategy per module (for discovery and review tooling).
• Define where baseline images live and how updates are reviewed.
• Add a small README for contributors on regeneration and diff expectations.

3. Module rollout

• Start with a pilot set of high-impact screens.
• Expand to most feature/* modules.
• Expand to common/* modules with reusable UI components.

4. Workflow integration

• Add guidance for using screenshot references during UI iteration.
• Integrate with skill-driven design loops so visual references are first-class artifacts.

5. Governance

• Define acceptance criteria for when screenshot coverage is considered sufficient per module.
• Define update policy for intentional visual changes.

Acceptance criteria (initial):

• A documented screenshot-testing convention exists and is discoverable in-repo.
• At least one pilot module demonstrates passing screenshot tests and baseline handling.
• A rollout checklist exists for feature/* and common/* modules.
• Visual artifacts are organized so designers/developers can reference them during iteration.

Module Rollout Checklist

feature/* modules

• feature/about
• feature/account
• feature/airing
• feature/auth
• feature/character
• feature/episode
• feature/feed
• feature/forum
• feature/image-viewer
• feature/media
• feature/medialist
• feature/news
• feature/notification
• feature/profile
• feature/recommendation
• feature/review
• feature/search
• feature/settings
• feature/staff
• feature/studio
• feature/suggestion
• feature/updater

common/* modules

• common/character
• common/editor
• common/episode
• common/feed
• common/forum
• common/genre
• common/markdown
• common/media
• common/medialist
• common/news
• common/recommendation
• common/review
• common/shared
• common/staff
• common/studio
• common/tag
• common/user

Additional Context

Source intent from prompt:

• Plan for using Android Studio Compose Screenshot Testing in our workflows.
• Treat this as a platform concern.
• Maintain screenshot folders that support iterative design workflows and visual references.
• Apply to most feature and common UI modules over time.