mirror of
https://github.com/nushell/nushell.git
synced 2026-10-28 17:05:03 +08:00
Piepmatz
cee2807df7
<!-- Thanks for contributing to Nushell! Before submitting, please read the contributing guide: https://github.com/nushell/nushell/blob/main/CONTRIBUTING.md This template helps reviewers understand your changes and allows us to generate high-quality release notes. --> ## Description <!-- Explain what this PR does and why. This section is intentionally flexible: - Describe the problem - Explain your approach - Include technical details if relevant Good examples: - "In this PR, I fixed..." - "In this PR, I added support for..." - "This change improves X by..." Write as much or as little as needed for reviewers to understand your changes. --> This PR updates the tests in `tests/hooks/mod.rs`. This was quite a complicated task as the hooks have to be evaulated which does not happen when just evaluating code snippets. So to make this work, I pulled out the eval hook behavior into isolated function that can be reused in other places. These are now used in `--testbin nu_repl` (even tho this will be removed) and in `run_with_hooks` in the `NuTester` to emulate that the repl behavior with respect to hooks. This also showed that the state of the `EngineState` after the clone was not necessarily clean, so I added that too with all the things that seemed like they should be separated. And finally I also made sure that errors and warnings are no longer reporting during testing to stdout or stderr. ## User-facing changes (Release notes) <!-- This section is used (mostly as-is) for https://www.nushell.sh/blog/ Describe how Nushell behavior changes from a user's perspective. Do NOT describe internal Rust changes here. Write in a release note style, for example: - "Added support for..." - "Fixed an issue where..." - "Nushell now supports..." - "Improved performance of..." If your changes do NOT affect users (internal refactors, cleanup, etc.), just write: - "n/a" - "nan" - or similar This tells us the change should not appear in the changelog. Tips: - Focus on observable behavior - Include examples if helpful - Keep it concise You can: - Write a short paragraph (will appear as a bullet point), OR - Use headings (###) if your change needs more structure Avoid writing things like: - "In this PR, I refactored..." - "This updates internal code..." You may leave this blank until the PR is ready. --> n/a --- <sub>Stack created with <a href="https://github.com/github/gh-stack">GitHub Stacks CLI</a> • <a href="https://gh.io/stacks-feedback">Give Feedback 💬</a></sub>