Skip to content

Status normalization: verify see*Status + document assertion helpers #22

Description

@fafera

Parent

Supersedes closed PRD issue #18.

What to build

Verify and document the assertion-helper layer now that #21 normalizes status inside the criteria chokepoint.

Because seeOrderStatus() / seeSubscriptionStatus() delegate to seeOrderInDatabase() / seeSubscriptionInDatabase(), and #21 added normalizeStatusInCriteria() to mapCriteria(), the assertion helpers are already normalized end-to-end once #21 lands. So this slice adds no production normalization code — it proves the behavior with acceptance tests and records the contract in docblocks. Normalization lives at a single chokepoint (the criteria layer), not duplicated per method.

This works because normalize() canonicalizes WC statuses to the prefixed form ('active''wc-active'), which is exactly what WooCommerce writes to the database — both legacy wp_posts.post_status and HPOS wc_orders.status store the wc--prefixed value (e.g. WooCommerce's own draft status is DB_STATUS = 'wc-checkout-draft', while the public getter strips the prefix). So both seeOrderStatus($id, 'active') and seeOrderStatus($id, 'wc-active') resolve to WHERE status = 'wc-active' and match the same row. Unknown/third-party statuses pass through verbatim and match as-is.

grab*Status() is not normalized. It delegates to the storage layer (not through mapCriteria()), so it preserves the raw wc--prefixed DB value. This asymmetry is intentional: test authors who use grab*Status() compare manually, as they do today.

Acceptance criteria

  • No production normalization logic is added to OrderMethods::seeOrderStatus / SubscriptionMethods::seeSubscriptionStatus — they continue to delegate to see*InDatabase() unchanged; normalization is supplied by Status normalization: criteria methods (see*InDatabase, dontSee*InDatabase, grab*IdFromDatabase) #21's criteria chokepoint.
  • Acceptance case in OrderCest: write order with 'wc-active', then seeOrderStatus($id, 'active') passes.
  • Acceptance case in OrderHPOSCest: same, against HPOS storage.
  • Acceptance case in OrderCest or OrderHPOSCest: seeOrderStatus($id, 'wc-active') also passes against the same row (prefixed form still works).
  • Acceptance case in SubscriptionCest: write subscription with 'wc-active', then seeSubscriptionStatus($id, 'active') passes.
  • Acceptance case in SubscriptionHPOSCest: same, against HPOS storage.
  • grabOrderStatus and grabSubscriptionStatus are verified untouched (still return raw DB value, e.g., 'wc-active').
  • Docblock on OrderMethods::seeOrderStatus includes the WC-prefix note (accepts both forms; non-WC statuses pass through).
  • Docblock on SubscriptionMethods::seeSubscriptionStatus includes the same note.
  • Docblock on grabOrderStatus / grabSubscriptionStatus explicitly notes the return value is the raw DB value (still wc--prefixed).
  • All existing acceptance tests still pass.

Blocked by

Metadata

Metadata

Assignees

Labels

ready-for-agentFully specified, ready for an AFK agent

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions