Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Test coverage for signed-in flows: fakes in CI, production canary, release checklist

Đang mở
#1,614 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
35/100
Loại issue
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
dart, firebase, flutter
Lĩnh vực
backend, mobile, testing

Hướng nghiên cứu

Start with the listed agent client directories and the existing callable routing split, then review sub-issues #1615–#1619 to find the scoped implementation work. This issue defines a multi-part testing strategy across fakes in CI, a production canary, and a release checklist; done means those parts are implemented as their sub-issues specify.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

enhancement

Goal

Cover signed-in flows (sign-in, send, receive, moderate, signed-in settings). Today nothing covers them: the integration suite signs in anonymously against the Auth emulator with a seeded profile and never calls a callable.

Approach

Real-account tests in CI would need a token vault with rotation (Kick refresh tokens change on every refresh), a public webhook tunnel, serialized runs, and constant upkeep. Instead, split the problem into three parts, as most apps that integrate with streaming platforms do:

Catches Where Sub-issue
Fakes in CI Our bugs in signed-in flows Every PR, required check #1615, #1616, #1617
Production canary Twitch or Kick changing their API, scopes or webhook delivery Production agent, every few minutes #1618
Release checklist Breakage on the third-party sign-in pages Manual, before each release #1619
1. Fakes in CI
  • Twitch: use the official Twitch CLI. twitch mock-api serves Helix with fake users and tokens; twitch event trigger / twitch event websocket send fake EventSub events.
  • Kick: no official mock exists, so write a small fake server covering only the endpoints we call: users, channels, chat, moderation, events/subscriptions. It also posts signed webhook deliveries using a test key pair.
  • Backend: point the backend's platform clients at the fakes through config. Most agent clients already take a BaseURL (agent/internal/clients/{twitch,kick}, jobs.TwitchURL/KickURL); a few hostnames are still hardcoded.
  • Signing in: mint a custom token from the Auth emulator for a seeded user and deliver com.rtirl.chat://success?token=… to the app. This runs the real app path except the third-party sign-in page.
  • Optional: record real API responses once, by hand, and replay them in the fakes so they don't drift from production.

Cloud Functions migration (#1551): callables are split between the Go agent and Cloud Functions behind rtchat-api.rtirl.com. The harness runs the agent for callables it already serves, and the Functions emulator only for the ones not yet migrated. One routing table holds that split, so each migration step only edits the table. Put fake-server config in the agent first. Only add it to Functions for callables that haven't moved yet; don't invest further in Functions code that's being retired.

2. Production canary

A dedicated canary bot account on each platform signs in once through the real app. From then on, production already stores and refreshes its token, so there's no vault and no tunnel. A scheduled agent job:

  • sends a message with a unique ID to the canary's own channel through the normal send path
  • checks that the message comes back through the webhook or EventSub into Firestore
  • cleans up after itself

Failures are logged in a structured form, and a Cloud Monitoring alert on those logs notifies the team.

3. Release checklist

Before each release, sign in with each platform on a real device. It takes a couple of minutes, and every app keeps this step manual because the sign-in pages resist automation.

Sequencing

  • #1615 (fakes) → #1616 (CI harness) → #1617 (test cases)
  • #1618 (canary) runs independently
  • #1619 (checklist) can be done anytime
  • The multi-session E2E (#1611) builds on #1616's harness once both have landed.

Out of scope

Real platform accounts in CI. Automating third-party sign-in pages.

Ngôn ngữ chính
Dart
Star
49
Fork
25
Merge trung bình
10 giờ 43 phút
Pull request đã merge (30 ngày)
217

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của muxable/rtchat

Tất cả issue của muxable/rtchat

Issue tương tự

Thêm issue về Dart

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.