CodeVetter · Repo Unpack · Testing signals
krahets/hello-algo
Testing is 'does it compile and run' rather than assertion-based verification. Each language has either a run-all harness (Python test_all.py, JS test_all.js), native test drivers used as print harnesses (Go _test.go, ctest), or compile-only checks (Rust cargo build, TypeScript tsc --noEmit, Java javac, C/C++ cmake builds). There are no unit-test assertions on algorithm outputs, no docs/link checking, no site-build CI, and no coverage tooling. Coverage gaps: zig and pythontutor have no workflow at all, and zh-hant/ja/ru code trees are outside every workflow's path filter.
- codes/python/test_all.py is the Python 'test suite': it subprocess-executes every chapter_*/*.py and fails only on non-zero exit codes — no assertion of output content, so crashes are caught but wrong results are not.
- The Python workflow additionally enforces formatting: 'pip install black' then 'black <code-dir>' runs black over the whole directory (applying rewrites, which CI then leaves uncommitted but fails on parse errors).
- codes/javascript/test_all.js is the JS harness: Deno expandGlob over chapter_*/*.js spawning 'node' per file via Deno.Command — also exit-code-only validation.
- Go 'tests' are print-only drivers: e.g. pkg/list_node_test.go's TestListNode builds a linked list and calls PrintLinkedList with no assertions; chapter _test.go files like array_test.go are labeled 'Driver Code' and only fmt.Println results.
- Rust CI is compile-only: rust.yml runs 'cargo build' and 'cargo build --release' — no 'cargo test' and no bin execution — while using the nightly toolchain via brndnmtthws/rust-action-rustup.
- TypeScript CI is type-check-only: npm run check → tsc with noEmit over chapter_*/*.ts; nothing is executed.
- Java CI compiles everything with 'javac -d <dir>/build <dir>/**/*.java' on JDK 11 and 17 — no execution — and is pinned to the retired ubuntu-20.04 runner with actions/setup-java@v3.
- C and C++ CI builds with CMake across gcc/clang/cl on ubuntu+windows and runs 'ctest' — but the CMakeLists only register executables (add_executable), so ctest success effectively means 'built and ran without crashing'.
- Path filters limit each workflow to codes/<lang>/ and en/codes/<lang>/ — changes to zh-hant/codes, ja/codes or ru/codes trigger no CI at all, and docs-only changes never exercise the code.
- zig (codes/zig, ~59 files with build.zig) and pythontutor have no workflow — no .github/workflows/zig.yml exists — so the zig corpus is completely unverified in CI.
- There is no CI job that runs 'mkdocs build' — the docs site, nav integrity, overrides templates and locale INHERIT configs are only exercised by the Docker image build, which itself is not run by any workflow.
- Non-determinism is inherent: samples use randomness (random_access picks random.randint indices, Rust uses rand::thread_rng, Go rand.Intn), which is one reason the harnesses check exit codes rather than golden output. (inferred)