lib/stellar.ts's transaction-building functions (build*Transaction, submitTransaction) have zero test coverage

[abayomicornelius]

Problem

src/lib/stellar.ts contains every function in the app that actually constructs a signable Stellar transaction and submits it to the network — buildPaymentTransaction, buildPathPaymentTransaction, buildBatchPaymentTransaction, buildTransactionFromQuote, submitTransaction, estimateFee, findPaymentPaths, resolveAsset — and none of it has a test file:

$ find src -name "*.test.ts*" | grep -v ".commits\|.merges"
src/components/BatchSend/BatchForm.test.tsx
src/components/ContactBook/SearchBar.test.tsx
src/components/Escrow/EscrowForm.test.tsx
src/components/Escrow/EscrowItem.test.tsx
src/components/ExchangeRate/RateBadge.test.tsx
src/components/PaymentRequests/CreateRequestForm.test.tsx
src/components/SendFlow/AmountStep.test.tsx
src/components/SendFlow/RecipientStep.test.tsx
src/components/Subscriptions/SubscriptionForm.test.tsx
src/components/TransactionHistory/Pagination.test.tsx
src/components/common/DarkModeToggle.test.tsx
src/components/common/FormField.test.tsx
src/components/common/NetworkError.test.tsx
src/components/common/Skeleton.test.tsx
src/context/WalletContext.test.tsx
src/hooks/useMediaQuery.test.ts
src/hooks/useTheme.test.ts
src/lib/api.test.ts
src/utils/format.test.ts
src/utils/stellar.test.ts
src/utils/validation.test.ts

There is no src/lib/stellar.test.ts. Meanwhile src/utils/stellar.test.ts — testing the much smaller, purely-cosmetic utils/stellar.ts (isValidStellarAddress, truncateAddress, xlmToStroops, stroopsToXlm — string/number formatting helpers with no network or SDK interaction) — is fully covered.

Why it matters

lib/stellar.ts is where real money actually moves: it builds the Operation.payment/Operation.pathPaymentStrictSend XDR that Freighter signs and Horizon executes, computes destination minimums under slippage, auto-detects memo type, estimates and sets transaction fees, and submits signed XDR to the network. Every one of the several other bugs filed against this exact file in this batch (memo type auto-detection, memo byte-length truncation, and the batch-fee multiplication issue) is the kind of defect a targeted unit test would have caught immediately — asserting on the shape of the built XDR (memo type, fee, operation count/amounts) requires no network access and no Freighter, just calling the exported builder functions with fixture input and inspecting the returned Transaction object before .toXDR().

Right now, the only place any of this logic gets exercised at all is indirectly, through component tests that mock the hooks calling into lib/stellar.ts (e.g. EscrowForm.test.tsx tests form validation, not the transaction that eventually gets built from a valid submission) — meaning a regression in fee calculation, memo handling, or path-payment construction could ship with the full test suite green.

Reproduction

• ls src/lib/*.test.ts → only api.test.ts exists; stellar.ts has no counterpart.
• Run npm test (or vitest run) and check coverage for src/lib/stellar.ts specifically — none of buildPaymentTransaction, buildPathPaymentTransaction, buildBatchPaymentTransaction, buildTransactionFromQuote, or submitTransaction is exercised by any existing test file.

Suggested fix

Add src/lib/stellar.test.ts covering, at minimum:

• buildPaymentTransaction: correct single Operation.payment, correct asset (native vs. issued), correct fee, and the memo-type/length behavior once those separate issues are fixed.
• buildPathPaymentTransaction: correct pathPaymentStrictSend operation shape, destMin computed from applySlippage/slippage tolerance.
• buildBatchPaymentTransaction: correct operation count matching recipients.length, and — most importantly given the fee-multiplication bug filed separately — an explicit assertion on the actual total fee field of the built transaction against a hand-computed expected value, using a mocked Horizon.Server/loadAccount so no network access is required (the existing api.test.ts already demonstrates the app's pattern for mocking the HTTP layer in tests).
• buildTransactionFromQuote: routes to path-payment vs. plain payment correctly based on quote.path.length.
• Error paths: toStellarAsset/assetFromCodeIssuer throwing for a non-native asset with no issuer; buildBatchPaymentTransaction throwing for zero or over-MAX_BATCH_RECIPIENTS recipients (both of which are already explicit throw statements in the source with no test asserting on them).

Additional Notes

• src/lib/stellar.ts (whole file, 420+ lines, zero coverage), contrasted with src/utils/stellar.test.ts (full coverage of a much smaller, non-transaction-building file).
• This is a distinct, narrower finding than the repo's existing "test suite is never run in CI or locally" issue (Test suite exists but is never run in CI or locally (no test runner installed, no test script) #1) — this is about a specific, high-value, currently-completely-untested module, independent of whether the suite as a whole is wired into CI.
• Given three other issues in this batch (memo type, memo byte-length, batch fee multiplication) are all bugs inside this exact file, adding coverage here has an unusually high chance of catching real, currently-shipping defects rather than just raising a number.