On 2024.02.26 18:26, René Scharfe wrote: > Am 26.02.24 um 10:28 schrieb Christian Couder: > > On Sun, Feb 25, 2024 at 12:27 PM René Scharfe <l.s.r@xxxxxx> wrote: > >> > >> Simplify TEST_CHAR_CLASS by using TEST for each character separately. > >> This increases the number of tests to 3598, > > > > Does this mean that when all the tests pass there will be 3598 lines > > of output on the terminal instead of 14 before this patch? > > Yes. > > > If that's the case, I don't like this. > > > >> but avoids the need for > >> using internal functions and test_msg() for custom messages. The > >> resulting macro has minimal test setup overhead. > > > > Yeah, the code looks definitely cleaner, but a clean output is important too. > > The output is clean as well, but there's a lot of it. Perhaps too much. > The success messages are boring, though, and if all checks pass then the > only useful information is the status code. A TAP harness like prove > summarizes that nicely: > > $ prove t/unit-tests/bin/t-ctype > t/unit-tests/bin/t-ctype .. ok > All tests successful. > Files=1, Tests=3598, 0 wallclock secs ( 0.08 usr + 0.00 sys = 0.08 CPU) > Result: PASS > > Filtering out passing checks e.g. with "| grep -v ^ok" would help when > debugging a test failure. I vaguely miss the --immediate switch from the > regular test library, however. Yeah, I agree here. It's a lot of output but it's almost always going to be consumed by a test harness rather than a human, and it's easy to filter out the noise if someone does need to do some manual debugging.
