Create Test Project

Skill: Create Test Project

Build a minimal compiled test project whose samples reproduce the flow a rule or approximation is verified against. A sample routes data between a real library method and the generic taint marker the scaffold provides, with the one verdict it must produce — a positive that must flag, a negative that must not. The compiled model is the deliverable; its sample sources sit alongside it.

Inputs

Provided by the caller, fall back to the default value when omitted. Ask back only when a required input is missing and has no sensible default

• project-root (optional) — root of the target project. Opentaint keeps all analysis artifacts under the fixed <project-root>/.opentaint/ directory, so every .opentaint/... path below resolves there. Default: current directory
• language (required) — target language for this project and language-specific instructions
• type (required) — what this project verifies, selecting the sample style and the identifying inputs below: rule-source, rule-sink, or dataflow
• for rule-source / rule-sink — unit: the unit id; its members and dependencies come from .opentaint/tracking/rules/sources|sinks/<unit>.yaml
• for dataflow — batch: the batch whose .opentaint/tracking/approximations/<batch>.yaml provides the dataflow methods to exercise and their dependencies

The project folder <name> is that identifier — the unit for a rule side, the batch for a dataflow approximation.

Workflow

1. Scaffold the project

The scaffold command and sample form are language-specific — read the reference for your type: references/<lang>-rule.md for rule-source / rule-sink, or references/<lang>-approximation.md for dataflow (one self-contained reference, no need to read the other). Scaffold the project for the type, passing each of the unit's dependencies at its pinned version. The scaffold provides the generic taint marker and the fixed test rule the samples run against, so you author only the samples. If the <name> project already exists — re-invoked because its surface grew or a dependency moved — extend it instead: add the missing samples and recompile rather than scaffolding fresh. The init command is in that reference.

2. Write the samples

For a unit or batch, each entry records its signature; shape a faithful sample from how that callable is really used in the project. The app's real path is irrelevant, only that data flows between the boundary and the marker:

For a sink unit, the methods are nested under groups[].sinks, exercise every method while preserving the group boundaries for the later rule author.

• the counterpart is always the generic marker, never a real source/sink, so the sample exercises only the unit under test
• register each sample under the single verdict it must produce — a positive that must flag, and, where the type calls for it, a negative that must not — in the test's rule-test.yaml

The sample code, the rule-test.yaml form, and which verdicts a type needs are in that reference.

3. Compile to the model

Compile the project you built to .opentaint/test-compiled/<name> — a rule side compiles the one sub-project you scaffolded (sources/ or sinks/) to the matching sub-model, a dataflow project compiles once:

# rule side — the one you built
opentaint compile .opentaint/test-projects/<name>/sources -o .opentaint/test-compiled/<name>/sources
# dataflow
opentaint compile .opentaint/test-projects/<name> -o .opentaint/test-compiled/<name>

A clean compile is the deliverable. Feedback loop: a build failure is a fixable samples-or-dependencies problem — surface the real error, fix it, and recompile. On a clean compile set the test-project stage done (per Tracking).

4. Escalate

When a project won't compile after ~3 fixes with no clear cause → report the failure and leave the test-project stage pending, for the orchestrator to intervene.

Output

Short and concise report of what was done

Artifacts

• .opentaint/test-compiled/<name> — the compiled test model a later stage runs against; report each path and the exact compile command used
• .opentaint/test-projects/<name> — the sample sources and the rule-test.yaml that records their verdicts, alongside the model

Summary

• the number of samples written per case
• any method excluded because no sample could be written (marked failed), with a brief reason
• failed projects (if any)