bug#65734: [BUG] kill-whole-line on folded subtrees [9.6.8 (release_9.6.8-3-g21171d @ /home/w/usr/emacs/0/29/0/lisp/org/)]

[Eli Zaretskii <eliz@gnu.org>]

> From: Sebastian Miele <iota@whxvd.name>
> Cc: 65734@debbugs.gnu.org, yantar92@posteo.net
> Date: Tue, 12 Sep 2023 15:04:41 +0200
> 
> > Looks reasonable, but I'm not sure I understand what will the test
> > show if one of the tests fails: will the information shown then tell
> > enough to understand which of the sub-tests failed and why?
> 
> That almost certainly would not be immediately obvious in the current
> state.  I have next to no experience in working with testing frameworks.
> But I assumed that regressions do not happen that often, and that it
> would be good enough if the code of the test can be grasped quickly.
> Then, in case of a regression, the test code can be temporarily
> sprinkled with some printf-like debugging to find out the exact location
> in the test.
> 
> However, enough of that printf-like debugging could also be hard-coded,
> like in the following definition (see the line ending in the comment
> "Provide some context"):

It should be enough to have an indication of what sub-test failed.
Finding that out in a series of tests one of which fails is frequently
a very frustrating experience, especially if the test is written with
heavy use of macros, or generates testing code on the fly (or both).

> With the always succeeding
> 
>   (should `(subtest ,kill-whole-line-arg)) ; Provide some context
> 
> at the beginning of ervery subtest, the context would be clear after
> pressing l in a buffer showing the ERT test results (but never on the
> console).

I mostly run tests in batch mode, so my preference is to see some
telltale indication of the failed code when ERT reports the failure.

> An alternative would be to use `message'.  That would also provide the
> context on the console.  However, that also may be a bit noisy.

The "noise" is required only when there's a failure.

One idea is to include the test ID in the string(s) you test for
equality, such that the diagnostics printed by ERT will inherently
include the test ID, and will allow finding the problematic code
easily.  For example, instead of

   "AB<POINT>"

you could use "TEST#1<POINT>" or something along those lines.

Thanks.