Work Order API Reference¶
The headerkit.workorder module assigns every declaration in a parsed unit to a test
tier and renders the generated test file and its markdown companions for a scaffolded
project.
Tier 1 emits real, passing tests where the IR determines both the call and the expected result. Tiers 2 and 3 emit deliberately failing stubs for behaviour no header records. See the Test work orders guide for what each tier covers and why the exclusions are exclusions.
Classes¶
WorkOrder
dataclass
¶
Everything the tiering pass derived from one source unit.
Tier1Test
dataclass
¶
A test whose call and expected value are both derived from the IR.
Stub
dataclass
¶
A failing test standing in for behaviour no IR can describe.
Functions¶
analyze_work_order
¶
Assign every declaration in unit to a tier.
A function reached by Tier 2 never also receives a Tier 3 stub, and records and enums never receive stubs at all, because Tier 1 tests them completely. Diluting the work order with items that are already covered is the way this feature fails: the reader stops reading it carefully.
Source code in headerkit/workorder.py
334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 | |
build_work_order_files
¶
Build the tiered test file and its two markdown companions for a scaffolded project.
Every file returned is marked preserve_existing: these are the artifacts a
human edits, and regeneration must not eat the work it asked for.
Source code in headerkit/workorder.py
Constants¶
WORK_ORDER_MARKER opens every stub failure message, in both languages, so a reader
can tell an unwritten stub from a genuine regression at a glance.
DEFINITION_OF_DONE is repeated on every stub: call it and assert on the result;
asserting that it does not raise is insufficient.
The rendering functions behind build_work_order_files are internal. Their output is
described in the Test work orders guide.