Arrange, act, assert

Informative guide. This Book page explains Beskid but does not define the standard. For normative requirements, use the Beskid Standard.

You do not need a Beskid port of xUnit’s 47 base classes. You need readable failure messages when the compiler disagrees with your story.

The pattern

flowchart LR
  accTitle: Arrange, act, assert
  accDescr: A test arranges inputs, acts by calling the unit under test, then asserts with corelib helpers or explicit checks.
  arrange["Arrange: inputs, fixtures, temp files"]
  act["Act: call the unit under test"]
  assert["Assert: corelib helpers or explicit checks"]
  arrange --> act --> assert

1. Arrange: build data, configure paths, materialize projects if the test is integration-weight.
2. Act: one logical operation (parse, resolve, lower, run entrypoint).
3. Assert: use corelib testing helpers (see corelib Testing docs) or explicit comparisons; failed assertions become test failures, not undefined behavior (Testing spec).

Keep tests boring on purpose

Good	Avoid
One reason to fail per test	Mega-tests that assert 40 unrelated diagnostics
Descriptive test names	test Foo copy-pasted fourteen times
meta.tags for speed tiers	Running the full compiler graph for “string literal parses”

Assertions and documentation

Test bodies can carry /// docs like other statements when you need to explain why a regression exists. Future you is also a developer.

When AAA is not enough

Integration tests that need multi-file fixtures belong in dedicated Test projects with explicit group prefixes. Push heavy assets to beskid_tests-style layouts in the compiler repo when you are locking platform behavior (Conformance vs unit).

Next

Conformance vs unit