Summary
Three of phoenix_kit_warehouse's own tests fail when the suite is run standalone (mix test in this repo alone, against a real Postgres DB, no host app). All three are missing test fixture/config setup that already exists and is used correctly elsewhere in this same test suite — this is not a behavior bug, and not something the linked commits below changed.
Found while fast-forwarding our fork's origin/main to upstream/main (bcc2f34 → a783d8c, 19 commits, zero commits unique to the fork) and running the full test suite as a verification step for that sync.
Proof these aren't caused by the 19 commits that were merged: none of the failing tests' own source or test files appear in the merge diff. The one touched test-infra file (test/test_helper.exs) only adds previously-missing setup (PubSub, RateLimiter, TaskSupervisor, test Endpoint, a default warehouse Location) — strictly an improvement, nothing removed. Full file list touched by the 19 commits:
CHANGELOG.md
dev_docs/pull_requests/2026/18-warehouse-gettext-pin/CLAUDE_REVIEW.md
lib/phoenix_kit_warehouse.ex
lib/phoenix_kit_warehouse/stock_ledger.ex
lib/phoenix_kit_warehouse/web/components/filter_chips.ex
lib/phoenix_kit_warehouse/web/goods_issue_form_live.ex
lib/phoenix_kit_warehouse/web/goods_receipt_form_live.ex
lib/phoenix_kit_warehouse/web/inventory_form_live.ex
lib/phoenix_kit_warehouse/web/settings_live.ex
lib/phoenix_kit_warehouse/web/stock_live.ex
lib/phoenix_kit_warehouse/web/transfer_form_live.ex
lib/phoenix_kit_warehouse/web/turnover_report_live.ex
mix.exs
mix.lock
priv/gettext/default.pot
priv/gettext/et/LC_MESSAGES/default.po
priv/gettext/ru/LC_MESSAGES/default.po
test/phoenix_kit_warehouse/gettext_test.exs
test/test_helper.exs
On the pre-merge tree these same three gaps would reproduce identically or worse (the old test/test_helper.exs didn't even start PubSub/the test Endpoint, so a larger set of tests would have failed harder, not softer).
1. "order" source_kind isn't registered — 4 failures
test/phoenix_kit_warehouse/goods_issues_test.exs:390 and :430test/phoenix_kit_warehouse/goods_receipts_test.exs:602 and :642
All four call add_source_ref(doc, "order", uuid) and assert {:ok, _}. valid_ref_type?/1 (lib/phoenix_kit_warehouse/goods_issues.ex:321, lib/phoenix_kit_warehouse/goods_receipts.ex:346) accepts an arbitrary kind only if it's in PhoenixKitWarehouse.SourceKinds.list_kinds/0, which reads Application.get_env(:phoenix_kit_warehouse, :source_kinds, []) — empty unless a test registers it. This package already ships exactly the fixture for this: test/support/fake_order_sources.ex (PhoenixKitWarehouse.Test.FakeOrderSources), and it's used correctly by internal_orders_test.exs, doc_refs_test.exs, transfers_test.exs, and source_kinds_test.exs. The two failing files just never call it — confirmed by grep, zero matches for source_kinds/FakeOrderSources in either file.
Suggested fix: add the same Application.put_env(:phoenix_kit_warehouse, :source_kinds, [FakeOrderSources.order_kind(), ...]) + on_exit cleanup these four tests' setup blocks that the other four files already have.
2. No FK-safe user for performed_by_uuid — 1 failure
test/phoenix_kit_warehouse/committed_quantities_test.exs:139 (assert at :167)
GoodsIssues.post_goods_issue(posted_issue, Ecto.UUID.generate()) — a random, non-existent UUID passed as the performer — raises Ecto.ConstraintError on phoenix_kit_warehouse_goods_issues_performed_by_uuid_fkey instead of returning {:ok, _}. This file never creates a real user anywhere. The fix already exists in this same test suite: test/phoenix_kit_warehouse/web/inventory_form_live_comments_and_modal_test.exs creates one inline (Auth.register_user/1 + Auth.admin_confirm_user/1) for exactly this reason ("Need a real user for the FK constraint").
Suggested fix: create a real user the same way before calling post_goods_issue/2.
3. Comments module isn't enabled — 1 failure
test/phoenix_kit_warehouse/web/inventory_form_live_comments_and_modal_test.exs:140 (assert at :168)
PhoenixKitComments.create_comment/4 is called directly and succeeds ({:ok, comment}), but the very next line, PhoenixKitWarehouse.Comments.count/2 (lib/phoenix_kit_warehouse/comments.ex:67), reads back 0. Comments.count/2 gates on available?/0, which is Code.ensure_loaded?(PhoenixKitComments) and PhoenixKitComments.enabled?() — and enabled?/0 (deps/phoenix_kit_comments/lib/phoenix_kit_comments.ex:97) reads the "comments_enabled" Settings row, defaulting to false when absent. Nothing in test/test_helper.exs or this test ever calls PhoenixKitComments.enable_system/0, so the write succeeds but the wrapper's own read reports the module as off.
Suggested fix: call PhoenixKitComments.enable_system/0 (or set the Setting directly) before this assertion, or in this test's own setup.
Is this a behavior bug or a test-isolation gap?
Test-isolation gap, all three. Nothing here indicates phoenix_kit_warehouse behaves incorrectly for a real Andi-hosted deployment — source_kinds is host-configured by design (see SourceKinds's own moduledoc: "with no host 'order' concept at all" is the documented degrade-gracefully case), comments being off-by-default is the correct default, and a real deployment always has real users. All three failures are specifically about what mix test sees when this one module's suite runs without the rest of Andi's stack wired in — which is exactly the situation test/test_helper.exs's recent PubSub/RateLimiter/Endpoint/TaskSupervisor/default-Location additions already exist to close for other subsystems. These three are the remaining gaps in that same effort, not a new class of problem.
Summary
Three of
phoenix_kit_warehouse's own tests fail when the suite is run standalone (mix testin this repo alone, against a real Postgres DB, no host app). All three are missing test fixture/config setup that already exists and is used correctly elsewhere in this same test suite — this is not a behavior bug, and not something the linked commits below changed.Found while fast-forwarding our fork's
origin/maintoupstream/main(bcc2f34 → a783d8c, 19 commits, zero commits unique to the fork) and running the full test suite as a verification step for that sync.Proof these aren't caused by the 19 commits that were merged: none of the failing tests' own source or test files appear in the merge diff. The one touched test-infra file (
test/test_helper.exs) only adds previously-missing setup (PubSub, RateLimiter, TaskSupervisor, test Endpoint, a default warehouse Location) — strictly an improvement, nothing removed. Full file list touched by the 19 commits:On the pre-merge tree these same three gaps would reproduce identically or worse (the old
test/test_helper.exsdidn't even start PubSub/the test Endpoint, so a larger set of tests would have failed harder, not softer).1.
"order"source_kind isn't registered — 4 failurestest/phoenix_kit_warehouse/goods_issues_test.exs:390and:430test/phoenix_kit_warehouse/goods_receipts_test.exs:602and:642All four call
add_source_ref(doc, "order", uuid)and assert{:ok, _}.valid_ref_type?/1(lib/phoenix_kit_warehouse/goods_issues.ex:321,lib/phoenix_kit_warehouse/goods_receipts.ex:346) accepts an arbitrary kind only if it's inPhoenixKitWarehouse.SourceKinds.list_kinds/0, which readsApplication.get_env(:phoenix_kit_warehouse, :source_kinds, [])— empty unless a test registers it. This package already ships exactly the fixture for this:test/support/fake_order_sources.ex(PhoenixKitWarehouse.Test.FakeOrderSources), and it's used correctly byinternal_orders_test.exs,doc_refs_test.exs,transfers_test.exs, andsource_kinds_test.exs. The two failing files just never call it — confirmed by grep, zero matches forsource_kinds/FakeOrderSourcesin either file.Suggested fix: add the same
Application.put_env(:phoenix_kit_warehouse, :source_kinds, [FakeOrderSources.order_kind(), ...])+on_exitcleanup these four tests'setupblocks that the other four files already have.2. No FK-safe user for
performed_by_uuid— 1 failuretest/phoenix_kit_warehouse/committed_quantities_test.exs:139(assert at:167)GoodsIssues.post_goods_issue(posted_issue, Ecto.UUID.generate())— a random, non-existent UUID passed as the performer — raisesEcto.ConstraintErroronphoenix_kit_warehouse_goods_issues_performed_by_uuid_fkeyinstead of returning{:ok, _}. This file never creates a real user anywhere. The fix already exists in this same test suite:test/phoenix_kit_warehouse/web/inventory_form_live_comments_and_modal_test.exscreates one inline (Auth.register_user/1+Auth.admin_confirm_user/1) for exactly this reason ("Need a real user for the FK constraint").Suggested fix: create a real user the same way before calling
post_goods_issue/2.3. Comments module isn't enabled — 1 failure
test/phoenix_kit_warehouse/web/inventory_form_live_comments_and_modal_test.exs:140(assert at:168)PhoenixKitComments.create_comment/4is called directly and succeeds ({:ok, comment}), but the very next line,PhoenixKitWarehouse.Comments.count/2(lib/phoenix_kit_warehouse/comments.ex:67), reads back0.Comments.count/2gates onavailable?/0, which isCode.ensure_loaded?(PhoenixKitComments) and PhoenixKitComments.enabled?()— andenabled?/0(deps/phoenix_kit_comments/lib/phoenix_kit_comments.ex:97) reads the"comments_enabled"Settings row, defaulting tofalsewhen absent. Nothing intest/test_helper.exsor this test ever callsPhoenixKitComments.enable_system/0, so the write succeeds but the wrapper's own read reports the module as off.Suggested fix: call
PhoenixKitComments.enable_system/0(or set the Setting directly) before this assertion, or in this test's ownsetup.Is this a behavior bug or a test-isolation gap?
Test-isolation gap, all three. Nothing here indicates
phoenix_kit_warehousebehaves incorrectly for a real Andi-hosted deployment —source_kindsis host-configured by design (seeSourceKinds's own moduledoc: "with no host 'order' concept at all" is the documented degrade-gracefully case), comments being off-by-default is the correct default, and a real deployment always has real users. All three failures are specifically about whatmix testsees when this one module's suite runs without the rest of Andi's stack wired in — which is exactly the situationtest/test_helper.exs's recent PubSub/RateLimiter/Endpoint/TaskSupervisor/default-Location additions already exist to close for other subsystems. These three are the remaining gaps in that same effort, not a new class of problem.