Repository navigation
fix(tests): wire orphaned keys.test into test suite and delete dead simulation_cache.test - #551
Conversation
…imulation_cache.test - Move src/alerts/keys.test.ts → tests/alerts/keys.test.ts with corrected import path so vitest picks it up (vitest.config.ts globs tests/**/*.test.ts). The test exercises real production code in src/alerts/keys.ts and all 3 tests pass. - Delete src/alerts/simulation_cache.test.ts. The SimulationCacheManager class it tests is defined inline in the test file itself — no corresponding production module exists (no src/alerts/simulation_cache.ts, no cache logic in src/rpc/client.ts or src/core/extension.ts). It was an orphaned TDD exercise with no production counterpart to verify. Closes TegoLabs#357 Closes TegoLabs#359
|
@MrG139 Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits. You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀 |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
💤 Files with no reviewable changes (1)
📜 Recent review details🔇 Additional comments (1)
📝 WalkthroughSummary by CodeRabbit
WalkthroughThe orphaned simulation cache test file and its in-file cache implementation are removed. The key tests now import the production alerts module while preserving their existing assertions and failure-case coverage. ChangesOrphaned test cleanup
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related issues
Possibly related PRs
Suggested reviewers: Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
| GitGuardian id | GitGuardian status | Secret | Commit | Filename | |
|---|---|---|---|---|---|
| - | - | Generic High Entropy Secret | ded54f4 | tests/commands/guard-cli-export-import.test.ts | View secret |
🛠 Guidelines to remediate hardcoded secrets
- Understand the implications of revoking this secret by investigating where it is used in your code.
- Replace and store your secret safely. Learn here the best practices.
- Revoke and rotate this secret.
- If possible, rewrite git history. Rewriting git history is not a trivial act. You might completely break other contributing developers' workflow and you risk accidentally deleting legitimate data.
To avoid such incidents in the future consider
- following these best practices for managing and storing secrets including API keys and other credentials
- install secret detection on pre-commit to catch secret before it leaves your machine and ease remediation.
🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.
…imulation_cache.test (#551) Relocates src/alerts/keys.test.ts (misplaced outside the vitest.config.ts include glob) to tests/alerts/keys.test.ts, and deletes the orphaned src/alerts/simulation_cache.test.ts (a self-contained duplicate reimplementation of a SimulationCacheManager, never wired to the real module). Verified locally: lint, typecheck, full suite (1042/1042), build, and audit all clean. Closes #357, #359.
What does this PR do?
Closes #357 — moves
src/alerts/keys.test.tsintotests/alerts/keys.test.tsso vitest picks it up (vitest.config.ts only globstests/**/*.test.ts).Closes #359 — deletes
src/alerts/simulation_cache.test.tsbecause it defines an inlineSimulationCacheManagerclass with no corresponding production module; no production simulation-cache implementation exists anywhere in the codebase.Why?
Both test files lived under
src/alerts/and were never executed by vitest, rendering them dead code. This PR either wires them back into the test suite (if their subject is real production code) or removes them (if they tested inline-only or nonexistent modules).Does this touch secret-key handling or transaction submission?
Checklist
npm test)npx tsc --noEmit)npm run lint)console.login core logic