[Chore] adapter-common has zero test coverage

[collinsezedike]

Description

packages/contracts/adapter-common/src/lib.rs has no #[cfg(test)] module at all, despite being shared scaffolding used by both blend-adapter and defindex-adapter. Every helper in it (require_not_initialized, store_vault_and_usdc, require_vault_auth, get_vault, get_usdc, get_or_not_initialized) is only ever exercised indirectly through the two adapters' own tests, which always initialize via __constructor first — so the "not yet initialized" branches are never actually hit by any test in the repo. For example, get_vault(env) returning None (the pre-init state) has zero direct coverage.

Acceptance Criteria

• A new #[cfg(test)] mod tests in adapter-common/src/lib.rs asserts get_vault(&env) returns None before store_vault_and_usdc is called, and Some(vault) after.
• A test asserts require_not_initialized returns Err(AlreadyInitialized) once VAULT_KEY is already set.
• cargo test -p adapter-common runs and passes.

[bigceejay19]

@bigceejay19 has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

Hi maintainer, I’m interested in this issue and confident I can complete it carefully within the Wave timeframe.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @bigceejay19 to this issue.

[belloaliyu11]

@belloaliyu11 has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

Hello Maintainer, I’d love to take ownership of this issue and submit a high-quality pull request once completed.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @belloaliyu11 to this issue.

[Chekuyermu]

@Chekuyermu has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

I will like to solve this issues if you can assign it to me

ℹ️ Repo Maintainers: To accept this application, review their application or assign @Chekuyermu to this issue.

[escaprt]

@escaprt has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

I’d like to work on Issue #655 because adapter-common provides shared initialization, storage, and authorization helpers used by both blend-adapter and defindex-adapter, yet the crate currently has no direct test coverage. This leaves important pre-initialization and already-initialized branches unverified.

I will first review packages/contracts/adapter-common/src/lib.rs and the way both adapters consume its helpers to understand the expected storage keys, return types, and error behavior.

I will then add a focused #[cfg(test)] mod tests directly to adapter-common/src/lib.rs. The first test will call get_vault(&env) before any initialization and assert that it returns None, then call store_vault_and_usdc and verify that get_vault(&env) returns Some with the expected vault address.

I will also add coverage for require_not_initialized by setting VAULT_KEY in instance storage and asserting that the helper returns the typed AlreadyInitialized error instead of allowing initialization to proceed.

Where useful, I will use the existing Soroban test environment and storage patterns rather than introducing new test infrastructure. The tests will focus on the helper contracts themselves instead of relying on the higher-level adapter tests to exercise them indirectly.

I will ensure the new tests remain deterministic and validate the actual public/helper behavior and typed errors without requiring external contracts or network access.

Finally, I will run cargo test -p adapter-common and confirm the new tests pass cleanly alongside the crate's existing build.

My goal is to establish direct regression coverage for the shared adapter initialization and storage helpers, especially the pre-initialization and duplicate-initialization states that are currently invisible to the test suite.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @escaprt to this issue.

[drips-wave]

Congratulations, @escaprt! 🎉 Your application was accepted by the repo's maintainers, and the issue is due on August 31, 2026.

🧑‍💻 @escaprt: Please resolve the issue such that the repo's maintainers have enough time to review your contribution before the due date. You'll earn Points for completing the issue on-time, which will make you eligible for a share of the Stellar Wave Program's reward pool.

Warning

When opening a PR, please link it to this issue to ensure it gets tracked accurately. Points are awarded when this issue is marked as completed by the maintainer.

🤠 Repo maintainers: Please keep an eye on the contributor's progress and review their work before the due date. You can manage this issue, including adjusting its complexity and points, here.

🌊 Happy Wave 🌊