`src/lib/wallet.ts` is the only module in `src/lib/` with no test file

[Jagadeeshftw]

Priority: High  ·  Area: Wallet integration / test coverage  ·  Est. effort: 7–10 h

📌 Problem

src/lib/ contains eleven modules. Ten have a matching .test.ts:

anchorsApi ✓   api ✓       errorReporter ✓   format ✓    metricsApi ✓
search ✓       settlementsApi ✓   theme ✓    toast ✓     types ✓
wallet     ✗   ← no test file

useWallet.ts — the hook — is tested (useWallet.test.ts). The underlying lib/wallet.ts module is not, so whatever the hook does not exercise is unverified.

Wallet code is where a frontend is least forgiving of untested branches, because the failure modes are almost entirely error paths that a manual happy-path check never reaches:

• Provider absent — the extension is not installed.
• User rejection — the connection prompt is dismissed.
• Network / chain mismatch — the wallet is on a different network than the app expects.
• Account change mid-session — the user switches accounts while connected.
• Disconnect — cleanup of listeners and cached state.
• Address validation — what the module accepts as a valid address.

Establish what wallet.ts actually exposes before writing anything. The inventory of its public surface and which branches useWallet.test.ts already covers is the first deliverable — it determines what is genuinely untested versus merely tested indirectly.

🎯 Design decision required

State and defend:

1. Coverage inventory. What does wallet.ts export, and which of those paths does useWallet.test.ts already reach? Report both, then scope your tests to the real gap.
2. Mocking strategy. Wallet providers are injected globals. Describe how you simulate presence, absence, rejection and chain mismatch deterministically, without depending on a real extension.
3. Behaviour that turns out to be wrong. If a test shows an error path is mishandled — a rejection surfacing as a generic failure, or listeners not cleaned up on disconnect — that is a bug report. Say so rather than writing the test around it.

🧩 Requirements and context

• Cover the error paths explicitly. A test that only proves a successful connection adds little.
• Listener cleanup on disconnect and unmount must be asserted — leaked listeners on account-change events are a real defect class.
• Tests must not require a real wallet extension and must run in CI.
• Do not change wallet.ts behaviour unless a test exposes a genuine bug; if so, report it prominently and fix minimally.
• Do not duplicate what useWallet.test.ts already covers — reference it instead.
• The repo configures 95% coverage thresholds; aim to meet them for this module.

🛠️ Suggested execution

1. Produce the export/coverage inventory.
2. Build the provider mock harness.
3. Test the happy path, then each error path.
4. Test disconnect and cleanup.
5. Report any defect found.

✅ Acceptance criteria

• The PR contains the inventory of wallet.ts exports and what useWallet.test.ts already covers.
• src/lib/wallet.test.ts exists, scoped to the genuine gap.
• Provider-absent, user-rejection and chain-mismatch paths each have a test.
• Disconnect and listener cleanup are asserted.
• Tests run with no real wallet extension.
• Any defect found is reported, not worked around.
• npx tsc --noEmit passes and the full suite is green.

🚫 Out of scope

• Adding support for additional wallet providers.
• Rewriting useWallet.ts.
• Enforcing coverage in CI — separate issue.

🧪 Verification

npm ci
npm test src/lib
npm test
npx tsc --noEmit

📤 What your PR must include

1. The export and existing-coverage inventory.
2. Your provider-mocking strategy.
3. Any defect the tests exposed.
4. Which paths you deliberately left to useWallet.test.ts.
5. Closes #<n>.

🔒 Security notes

Wallet connection is the trust boundary between the application and a user's keys. Untested error handling there means the interface's behaviour when something goes wrong is unknown — and the specific risk is a mismatch between what the UI reports and what actually happened. A chain mismatch presented as a generic error, or a rejected connection shown as connected, leads a user to act on a false belief about the state of their wallet.

📋 Guidelines

• Minimum 95% test coverage on changed lines
• Clear documentation
• Timeframe: 96 hours from assignment
• One logical change per commit; no merge commits

---

💬 Join our community

Working on this, or want to sanity-check your approach before you start? Come and ask — the maintainers are there and happy to help.

Telegram: https://t.me/Grainlify

[ugoocreates-pixel]

Hello, I would love to take on this issue. I'm a software engineer with over 4 years experience. and i'm confident I can resolve this issue

[grantfox-oss]

🦊 GrantFox — @ugoocreates-pixel has been assigned to this issue as part of the Third Campaign campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #427)
2. Your PR will be reviewed by the AnchorNet-Org maintainers

Good luck! Track your progress on GrantFox.