Tests, lint, and profiling

Add a document-level test#

Tinymist recognizes top-level function names following its test conventions. A small example is:

#let test-addition() = {
  assert.eq(1 + 1, 2)
}

#let bench-layout() = {
  for i in range(100) {
    let _ = i * i
  }
}

Open the file and inspect its gutter markers. The plugin detects appropriate document-level test-*, panic-on-*, and bench-* function declarations. An ordinary value named test-value, or a declaration scoped inside a code block, is not the same kind of test.

Run the file’s suite#

Use Run Typst Tests or a detected test gutter. Tinymist’s test command runs the file’s suite; the gutter does not promise a single-test filter. Read the actual scope/output before interpreting a passing marker as one isolated test run.

A missing Tinymist executable or unsupported command is a tool setup problem. An assertion failure in a launched suite is a test result. Configure the tool before debugging document logic.

Run lint#

Use Run Tinymist Lint to inspect supported analysis findings. Navigate to a result, review its context, and rerun after editing. Keep lint output distinct from compilation failures and unit-test assertions; each answers a different question about the document.

Profile the main file#

Use Profile Current File on the intended entry point to investigate expensive document processing. Compare runs of the same document/tool version and inspect the reported hot spots before rewriting templates.

A slow included chapter can be driven by repeated layout work in the main document. Keep the actual pinned entry point, root, fonts, packages, and tool versions in a reproducible performance report.