Toutsu/GmRelayBot
1
1
Fork 0
Code Issues 20 Pull Requests 1 Actions Packages Projects Releases 88 Wiki Activity

[E2E] Сценарии join/leave, waitlist, reschedule и уведомления #149

New Issue
Closed
opened 2026-06-16 11:42:51 +03:00 by Toutsu · 0 comments
Toutsu commented 2026-06-16 11:42:51 +03:00
Owner
Copy Link
Copy Source

Цель

Проверить поведение RSVP, waitlist, reschedule и уведомлений через реальный Telegram user client.

Выбранный подход

  • Один реальный Telegram test-аккаунт через WTelegramClient.
  • Фейковые участники создаются напрямую в PostgreSQL (через DatabaseAssertions.SeedFakeParticipantAsync) для сценариев, где нужен второй/третий игрок.
  • Time-mock на уровне БД: UPDATE sessions SET scheduled_at = ... и сброс флагов уведомлений, чтобы T-24h подтверждение и T-5m join link отрабатывали за минуты, а не часы.

Реализовано

  • DatabaseAssertions.cs — чтение PostgreSQL, проверка состояния сессий/участников/proposal, сидинг фейковых игроков, time-travel уведомлений.
  • JoinLeaveWaitlistRescheduleScenario.cs:
    • join до лимита;
    • join в waitlist при заполнении (с фейковым активным игроком);
    • ручное повышение из waitlist через /listsessions;
    • leave + автопродвижение из waitlist;
    • reschedule: инициация, ввод 2-3 вариантов, голосование, ожидание deadline-сервиса, применение нового времени;
    • T-24h RSVP-подтверждение и T-5m join link с проверкой сообщений в группе и полей в БД.
  • Program.cs теперь запускает и wizard-сценарий, и lifecycle-сценарий.
  • Обновлён tests/e2e/README.md — статус #149 и описание подхода.

Критерий приёмки

  • join/leave/waitlist работают как ожидается.
  • Reschedule применяется и обновляет сообщения.
  • T-24h и T-5m уведомления отрабатывают через time-mock БД.
  • Состояние в БД соответствует ожидаемому после каждого сценария.

Почему не в CI

Требует реального Telegram-аккаунта, работающего бота и БД; runner не включён в GM-Relay.slnx и не собирается в CI.

## Цель Проверить поведение RSVP, waitlist, reschedule и уведомлений через реальный Telegram user client. ## Выбранный подход - **Один реальный Telegram test-аккаунт** через WTelegramClient. - **Фейковые участники** создаются напрямую в PostgreSQL (через `DatabaseAssertions.SeedFakeParticipantAsync`) для сценариев, где нужен второй/третий игрок. - **Time-mock на уровне БД**: `UPDATE sessions SET scheduled_at = ...` и сброс флагов уведомлений, чтобы T-24h подтверждение и T-5m join link отрабатывали за минуты, а не часы. ## Реализовано - `DatabaseAssertions.cs` — чтение PostgreSQL, проверка состояния сессий/участников/proposal, сидинг фейковых игроков, time-travel уведомлений. - `JoinLeaveWaitlistRescheduleScenario.cs`: - join до лимита; - join в waitlist при заполнении (с фейковым активным игроком); - ручное повышение из waitlist через `/listsessions`; - leave + автопродвижение из waitlist; - reschedule: инициация, ввод 2-3 вариантов, голосование, ожидание deadline-сервиса, применение нового времени; - T-24h RSVP-подтверждение и T-5m join link с проверкой сообщений в группе и полей в БД. - `Program.cs` теперь запускает и wizard-сценарий, и lifecycle-сценарий. - Обновлён `tests/e2e/README.md` — статус #149 и описание подхода. ## Критерий приёмки - [x] join/leave/waitlist работают как ожидается. - [x] Reschedule применяется и обновляет сообщения. - [x] T-24h и T-5m уведомления отрабатывают через time-mock БД. - [x] Состояние в БД соответствует ожидаемому после каждого сценария. ## Почему не в CI Требует реального Telegram-аккаунта, работающего бота и БД; runner не включён в `GM-Relay.slnx` и не собирается в CI.
Toutsu added this to the Этап — E2E-тестирование Telegram + Web milestone 2026-06-16 11:42:51 +03:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
area:bot
Telegram bot and worker logic
 area:data
Database schema, migrations and persistence model
 area:discord
Discord bot service and Discord adapter
 area:infra
Infrastructure, runtime and deployment
 area:miniapp
Telegram Mini App dashboard
 area:platform
Platform-neutral abstractions and adapter boundaries
 area:shared
Shared domain and rendering contracts
 area:web
Blazor web dashboard
 in-progress
В работе (issue взят агентом)
 next-up
Recommended immediate backlog
 pending-approval
Ждёт согласования плана решения
 platform:discord
Discord-specific behavior or adapter work
 platform:multi
Cross-platform or platform-neutral work
 platform:telegram
Telegram-specific behavior or adapter work
 priority:p0
Critical priority
 priority:p0
Блокирующий приоритет: задача должна быть выполнена до признания решения production-ready
 priority:p1
High priority
 priority:p2
Medium priority
 priority:p3
Lower priority
 security
Security-sensitive work
 type:bug
Bug fix or corrective work
 type:chore
Maintenance and supporting work
 type:feature
New product functionality
 type:refactor
Structural change without direct feature growth
 type:test
Testing and coverage work
No Label
Milestone
No items
No Milestone Этап — E2E-тестирование Telegram + Web
Projects
Clear projects
No project
Assignees
Clear assignees
Toutsu
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Toutsu/GmRelayBot#149
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?