Build & ship · Test
Test
Tests run before anyone installs your package, with no outside CI service to wire up.
What it is
Running your package's tests is a built-in part of the platform, already wired in for you. There is no separate CI account to create and no YAML to paste into another company's product before your package can be tested.
A single test can be run in the same isolated work area the platform uses for a full run, with the exact same test invocation, so a result you get on your own machine is directly comparable to a result from a full run.
A person or automated checker holding the right credential inside your Hive can run your tests and sign that a specific version passed. That signed record travels with the release, in the same shared history the release itself lives in.
Whether a missing or failing test result blocks a release, only warns about it, or just shows as a badge is a policy each Hive chooses for the packages it hosts.
What a person using the package notices
Nothing directly while they are using your app. The effect shows up earlier, in the package manager: a Hive can be configured to flag or refuse a version that has no test record at all, so what a person notices is that the packages offered to them tend to be the ones that actually ran their tests.
What you do as a developer
Your package's tests live alongside its own code, and you run them through the platform's own runner rather than a bespoke script per package.
Write tests next to your code
There is no separate repository or service to register your package with before it can be tested.
Run one test while you iterate
A single test runs in the same locked, reusable work area a full run uses, with the same flags, so you are not debugging against a setup that differs from what a real run will do.
Publish, and the test record travels with it
When your release is published, whatever test attestation exists for that version is part of its record in the shared history, available to anyone deciding whether to install it or let it into a wider Hive.
The actual command your tests run under is a fixed, repo-wide invocation, so a local run and a platform run are never comparing apples to oranges:
// the same flags whether you run one test yourself or a full run runs all of them
deno test --allow-all --unstable-sloppy-imports
How it relates to other steps
CI
Continuous integration is what runs this same test invocation automatically, at scale, for every change to a repository.
Distribute
A version with a security-scan failure needs a distinct, later passing scan before its distribution can be announced. Test and scan attestations are what a distribution decision reads.
Package
The manifest that describes your package is what a handler and its tests both work against.