Improve integration testing in ctest.
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 45/100
- Issue type
- Refactor
- Clarity
- Mostly clear
- Activity status
- Quiet
- Tech stack
- rust
- Domain
- testing-qa
Research direction
Start in the tests folder and review how input files, pregenerated expected outputs, and the shared testing infrastructure are currently organized. Use test_mismatched_union_field, check_entrypoint, and the existing unwrap-based setup as the main examples. Done means separating outputs into output/, moving shared infrastructure to a common directory, and splitting tests into basic.rs and failures.rs with failure-specific assertions.
Written by the indexing model from the issue text.
Description
Currently, the tests folder in ctest is very cluttered. The input folder contains not only the inputs to the tests, but also the pregenerated expected outputs as well, making it difficult to work with.
Additionally, all the tests are in one file, which was fine when we started but now that we have more tests and specifically tests that do different things (like fail), it is not a good idea.
Finally, the current integration testing infrastructure uses a lot of unwraps, which makes it difficult to reuse the existing functions like check_entrypoint for making tests that expect failure.
The most recent test added for example, test_mismatched_union_field, would benefit greatly if we could just call check_entrypoint, assert that it failed, and also assert that it specifically failed due to cc errors.
This issue is made to get an idea about how the tests folder should be laid out.
To me, the obvious things are to seperate the pregenerated outputs into a seperate output/ folder, move all of the testing infrastructure to a common directory, and for now at least, separate the tests into two files, basic.rs an failures.rs, where the latter only has tests that are expected to fail.
- Dominant language
- Rust
- Stars
- 2.6k
- Forks
- 1.3k
- Avg merge
- 2d 13h
- Merged PRs (30d)
- 27
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
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 rust-lang/libc
-
Difficulty 1/5 Under an hour Newbie friendliness 90/100
Maintainers usually reply within 1 day
-
riscv32gc-unknown-linux-gnu: `timex` uses the 32-bit `c_long` layout (144 bytes), glibc's riscv32 `struct timex` is 208 bytesPossibly taken @compiler-segfault claimed this 3 days ago. OpenC-bug
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
rust-lang/libc#5697 · 3 comments ·
Maintainers usually reply within 1 day
-
Expose `open_how` on AndroidPossibly taken A pull request linked to this issue is open or already merged. Open
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
rust-lang/libc#5673 · 1 comment ·
Maintainers usually reply within 1 day
-
RTEMS: `dirfd` is not declaredPossibly taken A pull request linked to this issue is open or already merged. Open
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
rust-lang/libc#5655 · 1 comment ·
Maintainers usually reply within 1 day
-
C-bug O-macos
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
rust-lang/libc#5650 · 16 comments ·
Maintainers usually reply within 1 day
Similar issues
-
bug priority: medium
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
storytold/photocraft#12706 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
IngvarConsulting/unica#2822 ·
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100