Add direct unit tests for uncovered business-logic strategies in @vendure/core

[GabrielRoc]

Summary

Several pure business-logic strategies in @vendure/core currently have no direct unit tests. Coverage measurement shows their core methods (check() / apply() / calculation functions) are never invoked by a test — they are only exercised indirectly through integration/e2e tests of other components. The result is 0% function coverage on the promotion conditions and shipping calculators, and uncovered branches in the tax calculation strategies.

These files are ideal candidates for fast, database-free unit tests: the src/testing/order-test-utils.ts helpers allow constructing Order and RequestContext objects entirely in memory, so the logic can be tested in isolation without spinning up a TestServer.

Goals

• Add fast, deterministic unit tests that require no database and run with the existing Vitest unit suite.
• Raise function/branch coverage on isolated business logic that today is only covered transitively.
• Apply systematic test-design techniques (equivalence partitioning, boundary-value analysis, branch coverage) rather than ad-hoc cases.
• Keep each PR small and focused (one strategy / file per PR), per the contribution guidelines.
• No production code changes — pure test(core) commits targeting master.

Current coverage baseline

Measured with @vitest/coverage-v8 (v8 provider) over the target directories:

File	Line %	Branch %	Func %
config/promotion/conditions/buy-x-get-y-free-condition.ts	50.7	100	0
config/promotion/conditions/customer-group-condition.ts	44.4	100	0
config/promotion/conditions/contains-products-condition.ts	65.7	100	0
config/promotion/conditions/has-facet-values-condition.ts	67.7	100	0
config/promotion/conditions/min-order-amount-condition.ts	72.7	100	0
config/shipping-method/default-shipping-calculator.ts	72.9	100	0
config/shipping-method/default-shipping-line-assignment-strategy.ts	45.5	100	0
config/tax/default-order-tax-calculation-strategy.ts	100	78.1	100
config/tax/order-level-tax-calculation-strategy.ts	100	88.5	100

Note: the unit suite has no coverage tooling configured today. Measuring the baseline required adding @vitest/coverage-v8 (matching the existing vitest@3.2.4) as a dev dependency; this can be contributed separately as a small chore/test PR if desired.

Technical approach

• Vitest unit tests, co-located as *.spec.ts next to each source file (the established convention; run via the existing packages/core config).
• order-test-utils.ts to build in-memory Order, OrderLine, RequestContext, etc. — no DB, no TestServer.
• Test cases derived from the logic under test, e.g.:
  • buy-x-get-y-free-condition.ts: floor(matches / amountX) thresholds and the min free-item allocation (boundary-value analysis).
  • tax strategies: explicitly target the uncovered branches (rounding-per-group vs per-line; instanceof discrimination of OrderLine / Surcharge / shipping line).
  • default-shipping-calculator.ts: the three TaxSetting branches (auto / include / exclude).

Scope

Phase 1 — Promotion conditions (function coverage 0 → full)

• buy-x-get-y-free-condition.ts
• customer-group-condition.ts
• contains-products-condition.ts
• has-facet-values-condition.ts
• min-order-amount-condition.ts

Phase 2 — Tax calculation strategies (close branch gaps)

• default-order-tax-calculation-strategy.ts (78.1% → target full branch)
• order-level-tax-calculation-strategy.ts (88.5% → target full branch)

Phase 3 — Shipping calculators

• default-shipping-calculator.ts
• default-shipping-line-assignment-strategy.ts

Intent

I would like to implement these tests myself, submitted as a series of small
test(core) PRs referencing this issue.

---

Note: I am a Computer Science master's student at UTFPR — Campo Mourão (PPGCC-CM), contributing these tests as coursework credit for the Software Testing course. Feedback that helps the contributions meet the project's standards is very welcome.