2026 Bun 1.4.4 --changed: What to Do When Email Verification Tests Are Skipped?

Start with the changed-file boundary

Bun’s --changed option is an incremental selection mechanism, not a promise that every test in a project ran. The official documentation describes how it selects tests in relation to changed files and their test dependencies. The release notes for Bun v1.4.4 also record stability fixes involving bun test and bun test --changed; they do not identify a special email-testing failure or add a mail-specific test feature. Check the current Bun test documentation for the exact behavior supported by the version in your environment.

That distinction matters when a change affects a registration handler, email template, verification-token generator, or link-consumption route. A test can be present in the repository yet absent from the run if the runner cannot associate it with the changed code through the dependency relationships it observes. Conversely, a selected test file does not establish that every assertion passed, that the application sent a message, or that a recipient could read it.

Before interpreting a green result, identify the comparison point used by the command. A local run and a CI run can compare against different Git references, especially when a job checks out a branch, a merge commit, or a shallow history. Record the base reference and the exact command alongside the result. If the comparison point is wrong or unavailable, the selected change set may not represent the pull request or commit you intend to validate.

Why might bun test --changed miss email verification tests? Start by comparing the files reported as changed with the files the tests import. A test that exercises a template through a dynamic loader, generated file, runtime configuration, or dependency assembled outside a visible import path may not have an obvious relationship to the changed source. Do not infer the precise cause from a successful exit code; inspect the project’s dependency boundaries and the actual selection evidence.

Trace changes to the test files

Treat the change relationship as an observable property to verify, not as an assumption. For each email-related change, note which test is meant to protect it and how that test reaches the changed code. Keep this mapping small and concrete: a template change should point to a rendering or message-construction test; a registration handler change should point to a flow test; a verification-link change should point to token parsing and account-state assertions.

A static import is straightforward to inspect, but not every project uses one. Some applications choose templates by configuration, build paths dynamically, load generated artifacts, or select implementations at runtime. In those cases, the test runner may not see the relationship you have in mind. Review the runner’s documented selection behavior and the project’s actual module graph before relying on --changed to cover the path.

The Bun test configuration documentation is useful when configuration affects which files are considered tests or how the test command runs. Keep the distinction clear: configuration can shape discovery and execution, but it does not automatically create a dependency relationship between a changed source file and an integration test.

A practical review process is:

• Identify each changed mail-related file from the same base reference used by CI.
• Locate the test that asserts its expected behavior.
• Inspect whether that test imports the changed module directly or reaches it through a documented, observable path.
• For dynamically assembled or generated dependencies, confirm the runner’s observed boundary instead of assuming it follows runtime behavior.
• If the relationship is ambiguous, add a stable test path or run the relevant integration task explicitly.

This process is not a workaround for Bun. It is a way to keep the intended coverage visible to both the test runner and the people reviewing the CI result. If the project cannot make a dependency relationship clear, the reliable response is to run a named email integration task as part of the relevant validation job, rather than to treat incremental selection as full regression coverage.

Check what actually ran

The decisive evidence for test selection is the run itself: a test-file list, test names, or CI output that identifies the email-related cases. A process exit code is useful, but it reports the outcome of what was executed; by itself, it cannot show that an unselected test was included.

How can you tell which files Bun selected for a change? Use the output or report produced by the exact command and environment that CI uses. Compare the listed files and test names with the expected email regression cases. If the normal output does not make selection clear, capture the command’s output in the CI job or use the project’s configured reporting approach, then preserve that evidence with the build result. Avoid relying on a different local command as a substitute for the CI selection record.

Keep a short audit note with the changed files, selected email tests, and any known omissions. If the output lists the registration test but not the template integration test, record that difference and run the missing test directly. This turns “the build passed” into a reviewable statement about the coverage that actually occurred.

When email templates change, the relevant question is not merely whether the source file changed. Confirm that the intended test entered the CI run and that its assertions address the changed behavior. A snapshot may confirm rendered text while saying nothing about link validity. A handler test may confirm a send request while saying nothing about the recipient’s mailbox. Name the assertion and the evidence it supplies.

Validate the application flow separately

Use an explicit test task for the mail path when the release decision depends on it. The task can run a focused integration test, a dedicated mail suite, or another project-specific command. Keep it identifiable in CI so reviewers can distinguish it from the incremental check. The command should test your own product or an environment you are authorized to use; do not use this workflow to automate account creation on unrelated services.

For a registration or verification flow, confirm what each assertion observes:

• Message construction: the application generated the expected recipient, subject, body, and verification URL or code.
• Send handoff: the application called the configured mail adapter with the expected payload, or a controlled test adapter recorded the request.
• Verification assertion: the test extracted or supplied the expected link or code and confirmed the application accepts it under the intended conditions.
• Account-state assertion: the user record changed from the expected unverified state after the verification action.
• External receipt: a controlled recipient inbox displayed the message and its contents could be inspected.

These checks answer different questions. A mock can make a message request observable without sending anything outside the test process. An application-level assertion can prove that a route handles a token while saying nothing about provider acceptance. A real inbox check adds evidence that a message was readable at a destination, but it does not turn a single successful observation into a guarantee of future delivery.

What does a passing bun test say about actual delivery? It says that the tests selected for that run passed. If those tests use a mock or assert only application behavior, they do not prove that an external mailbox received the message. Label the result accurately in the test report; use a controlled receiving address when the release check requires evidence of real receipt.

For a controlled external check, use a test account and non-production data. Make the message identifiable with a test-specific address, token, or harmless marker, then verify the content and the action it supports. Keep secrets and real personal information out of fixtures and CI logs. Our guide to test data and privacy notices covers why realistic-looking test data still needs careful handling.

Choose the right validation path

Use these conditions to decide whether incremental testing is enough for the current change:

• If the changed files have a clear, observed relationship to the expected email tests, and the CI output shows those tests ran, use the incremental result for fast feedback; still run the project’s release-required checks before treating the change as fully accepted.
• If a template, generated artifact, runtime configuration, or dynamically assembled dependency makes selection unclear, run the relevant email integration test explicitly and record it separately.
• If the change affects a verification link, token handling, or account state, require assertions for those application behaviors rather than relying only on a template-rendering test.
• If the requirement is to know whether a person can read the message, use a controlled inbox check; do not substitute a mock, a green CI job, or an application log.
• If the account is important or must remain accessible over time, use a managed test mailbox rather than a disposable address. A temporary inbox is not a suitable recovery channel for a long-lived account.

This decision rule avoids turning every local edit into a full mail-system exercise, while preserving an explicit path for changes that incremental selection cannot reliably represent. The right choice depends on the release risk and the evidence required, not simply on whether the test command returned successfully.

Keep CI evidence in separate lanes

Incremental tests are useful for quick feedback when the change-to-test relationship is visible. They are not the same job as release acceptance. Keep the CI command, comparison base, selected test evidence, and integration-test result distinguishable in logs or reports. If a workflow runs both incremental and full checks, do not combine their outcomes into one vague “tests passed” label.

A focused CI record should answer these questions:

• Which Bun version and command ran?
• Which Git reference defined the change set?
• Which email-related test files or cases appeared in the run?
• Which application behaviors did those cases assert?
• Did a separate integration task run?
• Was external receipt checked, or was the evidence limited to an application-level test?

Bun v1.4.4’s release notes mention stability fixes for test execution, including --changed, but that is not a reason to infer that a particular skipped email test is a version defect. The selection result still needs to be inspected in the target environment. When Bun releases a later version or corrects its selection documentation, recheck the official release notes and test documentation before updating assumptions.

Verify real receipt only when needed

A real-receipt check belongs at the end of the evidence chain, not in place of the test suite. Use an isolated, controlled address for your own product. Inspect whether the message is readable and whether its content corresponds to the current test run. Keep the test identifier separate from production credentials, real customer data, and personal inboxes.

For receipt evidence, record what was observed without promising delivery beyond that observation. A message visible in a controlled inbox confirms receipt at that destination for that check. It does not establish universal inbox placement, future availability, or guaranteed delivery. For guidance on choosing between temporary and long-term addresses, see our disposable versus real email comparison.

Inboxonce can be an option when you need a temporary receiving address to inspect a test message without exposing a personal primary inbox. It is not a Bun test-runner integration, and it should not replace explicit assertions or a maintained mailbox for accounts that require long-term recovery. If you only need a controlled one-off registration or verification check, Inboxonce offers an immediately usable inbox without registration; that keeps test traffic apart from your main mailbox and reduces the chance that test messages clutter it.