GNU bug report logs - #57216
29.0.50; [PATCH] Provide ERT explainers for Eshell test functions

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#57216: closed (29.0.50; [PATCH] Provide ERT explainers for
 Eshell test functions)
Date: Tue, 16 Aug 2022 03:53:01 +0000

[Message part 1 (text/plain, inline)]

Your message dated Mon, 15 Aug 2022 20:52:09 -0700
with message-id <de70f9aa-2152-512d-840e-efa3877e9d1b <at> gmail.com>
and subject line Re: bug#57216: 29.0.50; [PATCH] Provide ERT explainers for Eshell test functions
has caused the debbugs.gnu.org bug report #57216,
regarding 29.0.50; [PATCH] Provide ERT explainers for Eshell test functions
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
57216: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=57216
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Jim Porter <jporterbugs <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Cc: eliz <at> gnu.org
Subject: 29.0.50; [PATCH] Provide ERT explainers for Eshell test functions
Date: Sun, 14 Aug 2022 14:20:25 -0700

[Message part 3 (text/plain, inline)]

It can be difficult to diagnose test failures in the Eshell ERT test 
suite, since it doesn't print useful details like the command that was 
executed. See bug#57129 for example.

Here are some patches to fix that. The failures now look like this:

----------------------------------------

    (ert-test-failed
     ((should
       (eshell-match-output regexp))
      :form
      (eshell-match-output "wrong")
      :value nil :explanation
      (mismatched-output
       (command "echo $INSIDE_EMACS[, 1]\n")
       (output "eshell\n")
       (regexp "wrong"))))

----------------------------------------

    (ert-test-failed
     ((should
       (eshell-command-result--equal command
                                     (eshell-test-command-result command)
                                     result))
      :form
      (eshell-command-result--equal "echo $LINES" 22 2)
      :value nil :explanation
      (nonequal-result
       (command "echo $LINES")
       (result 22)
       (expected 2))))

----------------------------------------

Most of the first two patches are purely-mechanical changes to update 
function calls. The diffs ended up being pretty big, but I think it 
improves matters. Let me know if I should do it differently (especially 
for the commit message; I didn't see much benefit to listing *every* 
test function I touched, but maybe I should do that?)

While I was testing these, I also found a couple real bugs with the 
'eshell-command-result' function. This throws 'eshell-defer':

  M-: (eshell-command-result "if {[ foo = foo ]} {echo hi}")

That's because 'eshell-do-eval' wasn't forwarding the SYNCHRONOUS-P 
argument in a couple spots.

This is also wrong:

  M-: (eshell-command-result "if (zerop 1) {echo yes} {echo no}")
    => nil

It should return "no".

I fixed these in the third patch. Maybe that could go in a separate bug, 
but it's fairly closely related to this one.

[0001-Provide-ERT-explainer-for-eshell-match-command-outpu.patch (text/plain, attachment)]

[0002-Add-eshell-command-result-equal-with-an-ERT-explaine.patch (text/plain, attachment)]

[0003-Fix-non-interactive-use-of-conditionals-in-Eshell.patch (text/plain, attachment)]

[Message part 7 (message/rfc822, inline)]

From: Jim Porter <jporterbugs <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: eliz <at> gnu.org, 57216-done <at> debbugs.gnu.org
Subject: Re: bug#57216: 29.0.50; [PATCH] Provide ERT explainers for Eshell
 test functions
Date: Mon, 15 Aug 2022 20:52:09 -0700

On 8/15/2022 12:01 AM, Lars Ingebrigtsen wrote:
> Jim Porter <jporterbugs <at> gmail.com> writes:
> 
>> It can be difficult to diagnose test failures in the Eshell ERT test
>> suite, since it doesn't print useful details like the command that was
>> executed. See bug#57129 for example.
> 
> I'm generally not in favour of making ert tests less trivial (because
> that makes dealing with them less easy if you're not familiar with the
> specific harness), but in this case, it makes sense, I think.

Agreed. I've tried to keep the tests as simple as I can, though even for 
the simplest of the Eshell tests, I think it's useful to show this info. 
 99% of the tests are "run some Eshell command and make sure it does 
the right thing", and if it fails, the new failure output is probably 
enough to debug it without even looking at the test code.

(Closing this, since I merged the patch.)

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.