@ton/sandbox tests.
Easy way
When using Blueprint, the only thing you need to collect coverage is to run the following command:coverage/ directory as HTML files with reports for each of your contracts.
Customizable way
There might be some reasons why you don’t want to simply use--coverage.
- You don’t want to collect coverage for all contracts.
- You use
@ton/sandboxbut don’t use@ton/blueprint. - Not all contracts have source code. (For example, for each transaction, you deploy a new contract, and you don’t have wrappers for it.)
- You want to get the raw data and customize the output.
1. Enable coverage collection
Before running tests, addblockchain.enableCoverage() to collect coverage data:
2. Collect coverage after tests
3. Generate reports
Understanding coverage data
Coverage summary
The coverage summary provides key metrics about your test coverage:Coverage reports
- HTML Report: Interactive report with highlighting and line-by-line coverage details
- Text Report: Console-friendly report with coverage information and marked code
Advanced usage patterns
Multiple test suites
When running multiple test files, you might want to merge coverage data:Coverage for multiple contracts
When testing systems with multiple contracts:not runnable
Interpret results
The usual report looks like this: Apart from the header statistics, the line-by-line coverage report is the most informative. Most fields are self‑explanatory; the code section shows per‑instruction hit counts (blue) and gas cost (red). This helps you analyze both coverage and gas efficiency.Limitations
Note that when code of other contracts is stored directly in the code of the contract (Tact does that automatically if a contract system does not contain circular dependencies), that affects the overall code coverage percentage. To mitigate this effect in coverage estimation, add a circular dependency. For example, import a file with the following content.Tact