Tests: skip test_get_build_command_in_last_line gracefully when g++ is unavailable
Nobody has claimed this yet.
Assessment
- Difficulty
- 1/5
- Estimated time
- Under an hour
- Newbie friendliness
- 78/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Quiet
- Domain
- testing-qa
Research direction
Open tests/test_build_markdown_cpp_cell.py and locate test_get_build_command_in_last_line. Check how the test invokes g++ and verify the behavior when g++ is unavailable. Done means the test is explicitly skipped without g++ and still runs its existing assertion when g++ is installed.
Written by the indexing model from the issue text.
Description
tests/test_build_markdown_cpp_cell.py::test_get_build_command_in_last_line shells out to g++ to compile C++ snippets extracted from notebook markdown cells, then asserts the exit code is 0. When g++ is missing the test fails opaquely with exit code 32512 (sh: 1: g++: not found), as happened on the first push that consumed the new pre-built test container (commit 07b9fb8c → fixed in 593c05fd by adding g++ to docker/Dockerfile.nmisp-test).
Suggested fix
Wrap the test (or the module) with a skip when the toolchain is absent:
import shutil
import pytest
@pytest.mark.skipif(shutil.which("g++") is None, reason="g++ not installed")
def test_get_build_command_in_last_line():
...
This makes the failure mode explicit (a clear SKIPPED instead of an exit-code-32512 AssertionError) the next time someone runs the suite outside the official container, and prevents a recurrence of the silent-toolchain-loss class of regression.
Why this matters
The current assertion couples the test outcome to the runtime environment rather than the code under test. A skipif decouples them — the test still verifies build-command extraction when a compiler is available, and clearly signals "no compiler" otherwise.
- Dominant language
- Jupyter Notebook
- Stars
- 12
- Forks
- 75
- PR merge metrics
- No merged PRs in 30d
Contributor guide
No contributing guide indexed for this repository
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 kangwonlee/nmisp
-
CI can't catch a missing Colab clone cell — add a static check (tests/test_colab_clone_cell.py) Open
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
kangwonlee/nmisp#442 ·
-
Pedagogy: move 00_introduction/40_how_to_draw_a_circle → 06_python_advanced/80_circle_case_study Openpedagogy
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
kangwonlee/nmisp#401 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
kangwonlee/nmisp#387 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
kangwonlee/nmisp#386 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
kangwonlee/nmisp#356 ·
All issues in kangwonlee/nmisp
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
copse-dev/agent-pane#2953 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 90/100
simonw/sqlite-utils#872 ·
-
calcite-components needs triage refactor
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Esri/calcite-design-system#15203 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 90/100
danielmiessler/LifeOS#2218 ·
-
kind/cleanup
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
kubernetes-sigs/kueue#15947 ·