Skip to main content
This guide explains how to write tests for smart contracts in Blueprint.

Use descriptive test names with “should”

Name tests using the “should” pattern. This makes test intent clear and failures easy to understand.

Prefer const over let

Use const for all variable declarations. Immutable bindings prevent accidental reassignments and make test behavior predictable. Tests using let with shared hooks can silently use wrong contract instances when setup changes.

Do not depend on state generated by previous tests

Make each test completely independent. Test execution order can change. Dependencies between tests create fragile suites where one failure cascades into dozens of false failures.

Single expect per test

Verify one specific behavior per test. When a test has multiple assertions and fails on the second, the third never runs. This masks additional bugs and forces sequential debugging instead of catching all issues at once.

Extract shared logic into test functions

When multiple contracts share similar behavior, extract that logic into a reusable test function. This reduces duplication and ensures consistent testing across related contracts. See example in the HotUpdate test suite.

Use setup() function

Extract common test setup into a dedicated function. This reduces duplication and improves maintainability. When initialization logic changes, updating it in one place prevents errors and inconsistency.

Component-based test organization

Organize tests by functional components. Large protocols have individual contract tests and integration tests. Separating concerns makes it clear what broke.

Gas and fee considerations

Fee validation is critical in TON because transactions can halt mid-execution when funds run out. Consider this scenario with Jetton transfers: Alice sends 100 jettons to Bob. The transaction successfully debits Alice’s jetton wallet, but Bob never receives the tokens. Insufficient fees prevented the message from reaching Bob’s wallet. The tokens are effectively lost. Always validate that gas constants and fee calculations are sufficient for complete transaction execution. See more details in the gas documentation.

Discovering minimal fees

Calculate required fees using formulas, but empirically discovering the minimal amount provides practical validation. Use binary search to efficiently find the threshold:

Advanced testing patterns

Testing all message fields

When testing messages, verify all important fields to ensure complete correctness.