Pull-request-triggered verification
Connect selected public or private GitHub repositories and run a check for each pull request, either on every push or when requested with a `/trycase run` comment.
TryCaseは、GitHubのプルリクエスト向けAI支援型エンドツーエンドテストツールです。使い捨てのLinux環境で影響を受けるユーザーフローを実行し、判定結果、動画、スクリーンショット、失敗の詳細をプルリクエストに投稿します。
TryCase tests pull requests by reading the code changes, selecting the user journeys they affect, and exercising those journeys in a disposable Linux environment. Web applications are tested in a browser, while APIs, CLIs, workers, and packages are exercised through their real commands.
Each run produces a verdict and supporting evidence on GitHub, including a captioned video and final screenshot. TryCase is designed to provide pull-request feedback without requiring teams to write or maintain a browser test suite.
Connect selected public or private GitHub repositories and run a check for each pull request, either on every push or when requested with a `/trycase run` comment.
TryCase reads the pull request and determines which user journeys or changed flows to test, rather than requiring a separately authored browser test for each run.
The service opens web applications in a browser and works through them like a user; APIs, CLIs, workers, and packages are exercised through their real commands. Monorepos are supported through repository setup that discovers the applications once and replays the setup for later runs.
Results include a pass or fail verdict, a captioned run video, and a final screenshot. Failure comments explain what was expected and what actually happened.
Users can connect a ChatGPT subscription through Codex or provide an OpenRouter API key and supported model. TryCase Auto runs the model connection on the service side; Claude subscription support is listed as coming soon.
The Node 20+ CLI can start, follow, continue, stop, and inspect verifications, and can list or download artifacts. Requested development or test secrets are sent by approved names from an environment or file rather than as command-line values.
A team can use a pull-request run to check a changed screen or user flow and review the recorded walkthrough alongside the GitHub verdict before deciding what ships.
Projects that do not maintain end-to-end browser tests can have TryCase infer affected journeys from the pull request and exercise the live application instead of first creating a test suite.
Teams working on APIs, command-line tools, workers, or packages can use the same verification workflow through real commands, provided the software and setup run on Linux.
Monorepo teams can configure application setup once and have later runs replay it while the agent focuses on the pull request’s affected targets.
Developers and automation can use the CLI to start a pull-request verification, stream status as NDJSON, respond to attention requests, and retrieve saved screenshots or captioned videos.
No. TryCase reads the pull request, identifies the user journeys affected by the changes, and attempts those journeys. It is intended to avoid writing and maintaining a separate browser test suite for this workflow.
Install the TryCase GitHub App on selected public or private repositories. Each pull request then receives its own check and a result comment. The trigger can be every push or an explicit `/trycase run` comment.
A completed run returns a pass or fail verdict, a captioned video of the run, and a final screenshot. If a check fails, the pull-request comment describes the expected and actual behavior.
Yes, the site says it can test anything that runs on Linux. Web interfaces are exercised in a browser, while APIs, CLIs, workers, and packages are tested through their real commands.
Each pull request receives its own disposable environment with 4 vCPUs and 8 GB of memory, without swap. The environment is deleted when the run ends, and the site recommends using non-production values.
トラフィックデータは参考情報としてご利用ください。