# shunit2 2.1.8 — shUnit2, the xUnit test framework for shell scripts. # # WHAT THIS PORT HAS TO ESTABLISH. shunit2 is one POSIX-sh script and the recipe # does nothing but `install -D` it, so there is no compile to get wrong and # "it built" says almost nothing. What can go wrong on this arm is that the # framework runs and reports the WRONG VERDICTS -- and a framework that reports # everything as passing is indistinguishable from `true`. So the payloads below # have verdicts known in advance and the assertions name the exact reported # counts and exit status. # # WHY FOUR PAYLOADS. # data/shunit2-criterion.sh the ticket's own criterion -- one passing, one # deliberately failing, one skipped case. Must # report all three and exit NON-ZERO. # data/shunit2-features.sh the API a real test author writes against, all # of it green, exit 0. The opposite polarity: the # two together show the verdict tracks the tests # rather than the runner. # data/shunit2-negative.sh fourteen assertion and failure forms, each made # to fail exactly once. This is what makes the # green of the features payload mean something: an # `assertEquals` that returned 0 unconditionally # would leave that file just as green and would # redden all fourteen cases here. Confirmed by # doing it, not assumed. # data/shunit2-contains.sh the assertContains / assertNotContains family, # alone, because it is the one part of shUnit2 # that does NOT work on this arm -- see below. # # WHY THE CONTAINS FAMILY IS RED, AND WHY THAT IS THE PLATFORM'S FAULT. # Both forms are `echo "$container" | grep -F -- "$content" > /dev/null`, and # that idiom is broken on this image by brintos/linux#87: splice(2) is unwired # in the wasm32 syscall table, GNU grep drains a FIFO with splice() whenever # stdout is /dev/null, gets ENOSYS, and exits 2 on a SUCCESSFUL match. So # "needle is present" reads as "not found" here. shunit2/platform-splice below # probes that idiom directly and is the anchor the two contains reds point at; # nothing about shUnit2 is at fault and there is nothing to patch in the recipe. # # BRINTOS-WORKAROUND: brintos/linux#87 remove — the contains cases and the zsh # arm carry the issue in their detail, purely because splice(2) is unwired. # They are left FAILING rather than skipped, so they flip green on their own the # day #87 closes and the zsh arm starts driving the real criterion cases; this # comment and the attribution text are then the whole of what is left to delete. # # WHY BOTH SHELLS, AND THEN TWO MORE. Shell portability IS this package's # claim, so the criterion is driven under every shell the image ships -- bash # and dash (the two the ticket names) plus mksh and zsh -- and each must report # the identical verdict. Three of the four do. zsh cannot be reached until #87 # is fixed: shUnit2's own zsh check is `setopt |grep "^shwordsplit$" >/dev/null`, # the same broken idiom, so it refuses to start under zsh on this image whatever # the caller does -- which is one attributed red, not a gap in the port. # # WHY failures=2 FOR ONE DELIBERATE FAILURE. shUnit2 counts a test function # that returns non-zero as a failure IN ADDITION to any assertion that failed # inside it, and an assertion is the natural last statement of a test -- so the # criterion payload's single wrong answer is reported twice, once as # `ASSERT:...` and once as `testDeliberateFailure() returned non-zero return # code.` Both lines are asserted by name so the count is pinned to its # mechanism and not merely to a number. The other payloads end every test # `return 0` for exactly this reason, which is why their counts are the plain ones. # # WHY SHUNIT_COLOR IS SET. The default is `auto`, which resolves through # `tput colors` and falls back to SIXTEEN when tput fails -- it never consults # isatty(3), so shUnit2 emits ANSI escapes into a pipe. Every capture here # therefore pins the colour mode explicitly rather than depending on the # guest's TERM, and the colour machinery gets its own two cases. # # WHY THE EXTERNAL COMMANDS GET CASES. Test discovery is # `egrep