# Testing Strategy

`Weld` needs both fast internal tests and generated-artifact integration tests.

## Repo Test Layers

## Unit And Planner Coverage

These tests cover:

- manifest normalization
- workspace discovery
- project loading
- graph traversal
- artifact planning
- affected-file analysis

## Generated Artifact Integration

These tests cover:

- projecting a standalone Mix artifact (package-projection and monolith modes)
- compiling the artifact
- running welded artifact tests
- building docs
- building the Hex tarball when `verify.hex_build` is enabled
- preparing and tracking bundles for internal-only artifacts even when no
  tarball is present
- running `mix hex.publish --dry-run --yes` when `verify.hex_publish` is enabled
  in package-projection mode
- compiling the smoke app when configured (package-projection mode)
- monolith test baseline gate: asserting the merged artifact runs at least as
  many tests as the sum of selected-package baselines
- monolith source-only test support policy: asserting any non-selected support
  projects are explicitly declared when the manifest opts into that contract

## Fixture Strategy

This repo uses two complementary fixture shapes:

- a workspace without a root `mix.exs`
- a workspace with a root `mix.exs` and `blitz_workspace`

That keeps the discovery model honest while still allowing fast tests.

## Source Lane Versus Artifact Lane

The generated package is intentionally tested as a standalone package, not as a
full mirror of every source-project test tree.

That means:

- source-repo tests remain the place for the full source-level suite
- welded artifact tests remain the place for package-level correctness

## Verification Goal

The target is not just "projection succeeded". The target is:

- the artifact is structurally correct
- the artifact is testable
- the artifact is buildable
- the artifact is trackable and archivable even when it is intentionally not
  Hex-buildable
- the artifact is publishable when Hex verification is enabled