bug#50629: 28.0.50; hard to debug an uncaught error with ert

["Gerd Möllmann" <gerd.moellmann@gmail.com>]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Mike Kupfer <mkupfer@alum.berkeley.edu> writes:
>
>> Knowing that error "bar" was raised is helpful, but in a more realistic
>> test scenario, it can take some time to figure out where the error was
>> raised.  Setting debug-on-error to t doesn't help (does ert hijack the
>> normal error handling mechanisms?).
>
> (I'm going through old bug reports that unfortunately weren't resolved
> at the time.)
>
> I'm not that familiar with ert internals, but yes, I think that's
> basically what ert does -- it hijacks the error/debug reporting system
> to implement the `should' macros.
>
> I've briefly poked at this now, but without any success in getting
> better backtraces for actual errors (which would indeed be very nice to
> have).
>
> Anybody more familiar with ert.el know how this can be achieved?

Not exactly this, I guess, but maybe as source of an idea?

diff --git a/lisp/emacs-lisp/ert.el b/lisp/emacs-lisp/ert.el
index 047b0069bb..1ffa0b5929 100644
--- a/lisp/emacs-lisp/ert.el
+++ b/lisp/emacs-lisp/ert.el
@@ -1495,6 +1495,8 @@ ert-run-tests-batch
                  (let ((print-escape-newlines t)
                        (print-level ert-batch-print-level)
                        (print-length ert-batch-print-length))
+                   (ert--pp-with-indentation-and-newline
+                    (ert-test-result-with-condition-should-forms result))
                    (ert--pp-with-indentation-and-newline
                     (ert-test-result-with-condition-condition result)))
                  (goto-char (1- (point-max)))

leads to output

Test f condition:
    (((should
       (equal 42
	      (foo)))
      :form
      (signal void-function
	      (bar))))
(void-function bar)