Add focused tests for FreeBSD VM console parsing
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- Half a day
- Newbie friendliness
- 84/100
- Issue type
- Feature
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- python
- Domain
- operating-systems, testing-qa
Research direction
Start with tools/check_freebsd_sys.py and trace Console.expect, including its buffering, EOF, timeout, and guest-log behavior. Add focused standard-library unit tests for single-read and split-read matches, consumption with later buffered output, EOF, timeouts, and log writes; done means they run without QEMU or FreeBSD assets while the existing VM flow remains unchanged.
Written by the indexing model from the issue text.
Description
Current evidence
tools/check_freebsd_sys.py contains a Console helper that incrementally reads the QEMU serial stream, appends bytes to a text buffer, searches regular expressions across reads, consumes matched prefixes, reports EOF, and enforces timeouts.
Those behaviors are independent of actually booting FreeBSD, but they are currently exercised only as part of the full VM workflow. Regressions in split serial output or buffer consumption therefore require an expensive QEMU run to detect.
Scope
- Add focused Python unit tests for
Console.expectwithout launching QEMU or requiring a FreeBSD image. - Cover a match contained in one read and a match split across multiple reads.
- Verify matched text is consumed while later buffered output remains available to the next
expectcall. - Cover EOF before a match, timeout behavior, and guest-log writes.
- Keep the production VM boot and shutdown flow unchanged.
Completion criteria
- Tests run on a normal development/CI host with only the Python standard library.
- No QEMU, firmware, disk image, network, or compiler invocation is required by the focused tests.
- Existing FreeBSD system-test behavior remains unchanged.
- Dominant language
- Rust
- Stars
- 56
- Forks
- 21
- Avg merge
- 2h 37m
- Merged PRs (30d)
- 57
Getting set up
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from wavefnd/Wave
-
enhancement good first issue needs testing
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
enhancement good first issue needs testing
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
enhancement good first issue needs testing
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
enhancement good first issue needs testing
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Maintainers usually reply within 1 day
-
enhancement good first issue needs testing
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Maintainers usually reply within 1 day
Similar issues
-
area:casework bug criticality:p3 triage:needs-implementation
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
registrystack/registry-stack#1623 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
leptos-rs/leptos#4885 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
longbridge/gpui-kit#3276 ·
Maintainers usually reply within 1 day
-
A-Migration Guides D-Straightforward S-Ready-For-Implementation X-Uncontroversial
Difficulty 1/5 Under an hour Newbie friendliness 88/100
bevyengine/bevy-website#2607 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day