Skip to main content
Run bugster update to automatically create tests for new functionality, modify tests impacted by code changes, and delete tests for removed features. Use it locally on demand or automatically on every pull request via the GitHub App. In this guide you will learn:
  • How to keep your test suite synchronized with your codebase using bugster update.
  • How to use different update modes for local development and CI workflows.
  • How to compare changes against different baselines like the default branch or the last update.

Prerequisites

  • Bugster CLI installed and authenticated.
  • Run commands from your repo root (the directory containing /.bugster/).
  • For PR automation: the Bugster GitHub App is installed on the repo (document required permissions) and PR previews are available if your flow depends on them.

​
Usage Modes

​
Local (manual)

Run bugster update when you’re confident about local changes and ready to sync them. The command analyzes committed changes only - both staged and unstaged files are ignored. Only differences between commits are considered for test updates. 
# Full update (create/modify/delete as needed)
bugster update
Scope flag precedence: If multiple scope flags are provided, the command will error and ask you to specify only one scope option.

​
Automatic on Pull Requests

When you open a Pull Request, Bugster’s E2E agent runs bugster update first. New commits or force-pushes will amend the existing Update PR rather than creating a new one.
1

Bugster creates an Update PR

Bugster opens a secondary PR targeting your feature branch with the suggested test suite changes.
2

Review the results

The original PR gets a comment with the test results and a link to the “Bugster Update PR”.
3

Approve and merge

You approve and merge the “Bugster Update PR”.
4

Merge your feature

Once the test updates are in, you can merge your feature branch.
Remember to review the Bugster Update PR before merging your feature.
Here is a summary of the flow: 
You create a PR  →  bugster update runs  →  Bugster opens "Update PR" → 
Bugster comments results in original PR → you review/merge Update PR → merge feature PR

​
Comparison Baselines

Choose the comparison model that fits your development stage:
BaselineUse WhenCommand
Last commit (default)Small, isolated editsbugster update
Default branchBefore PR / comprehensive sweepbugster update --against-default
Since last updateTight inner loop without reprocessingbugster update --against-last-update

​
Last commit (default)

When to use: Small, isolated edits 
bugster update
Scope: Compares your latest commit against the previous commit. Only sees files changed in your most recent commit.

​
Against default branch

When to use: Before PR / comprehensive sweep 
bugster update --against-default
Scope: Compares your current branch against the merge-base with the default branch (e.g., main). Sees all changes in your feature branch.

​
Since last update

When to use: Tight inner loop without reprocessing 
bugster update --against-last-update
Scope: Compares changes since the last time you ran bugster update. The “last update” state is stored in .bugster/state/last-update-hash and tracks the commit hash from your previous update.
ScenarioCommandUse Case
During active developmentbugster update --against-last-updateTight feedback loop
Before opening a PRbugster update --against-defaultFinal, comprehensive sweep
For small, isolated editsbugster updateDefault mode usually sufficient

​
Examples

Here are common scenarios and the commands to use. 
# Create/modify/delete as needed for just-touched files
bugster update

# Full branch comparison before PR
bugster update --against-default

# Tight inner loop; don't reprocess old changes
bugster update --against-last-update

# Limit to modifications only (no new/deleted tests)
bugster update --update-only

# Generate suggestions for new areas only
bugster update --suggest-only

# Purge tests tied to removed features
bugster update --delete-only

# Combine scope + baseline
bugster update --against-default --update-only

​
Review Tips

  • Always review the Update PR diff before merging.
  • Keep descriptive commit messages (e.g., bugster: update tests for billing portal flow).
  • If a change looks incorrect, adjust the code or the test, rerun bugster update, and re-review.
That’s it: one standardized command keeps your suite aligned with real product changes—locally or automatically on every PR.
⌘I