From: Stephen Berman <stephen.berman@gmx.net>
To: Noam Postavsky <npostavs@users.sourceforge.net>
Cc: Emacs developers <emacs-devel@gnu.org>
Subject: Re: Some testing issues
Date: Sat, 08 Jul 2017 16:50:28 +0200 [thread overview]
Message-ID: <87zicfnft7.fsf@rosalinde> (raw)
In-Reply-To: <CAM-tV-8pHTWWqWf7NBMtGqqY+0_+VeL_K=tXmZyUJ02Q+u5O0Q@mail.gmail.com> (Noam Postavsky's message of "Sat, 8 Jul 2017 00:20:23 -0400")
On Sat, 8 Jul 2017 00:20:23 -0400 Noam Postavsky <npostavs@users.sourceforge.net> wrote:
> On Fri, Jul 7, 2017 at 5:22 PM, Stephen Berman <stephen.berman@gmx.net> wrote:
>> Several of the tests call the function todo-toggle-view-done-items,
>> which contains this code:
>>
>> (if (not (pos-visible-in-window-p shown))
>> (recenter)
>>
>> (`shown' stores the position of the first done item in the category, if
>> it is shown.) When using todo-mode and also when stepping through the
>> function with Edebug, it works as expected.
>
> If I comment out the set-window-buffer call it fails for me in Edebug
> as well (when running the first time).
You're right, I must have misrembered or been thinking of a different
case; sorry.
> By the way, in order to run successfully I did also need the following
> patch, otherwise all the tests failed (I think it only happens for me
> because I'm running from an Emacs that's living under my home
> directory).
>
> modified test/lisp/calendar/todo-mode-tests.el
> @@ -46,6 +46,7 @@ (defmacro with-todo-test (&rest body)
> "Set up an isolated todo-mode test environment."
> (declare (debug (body)))
> `(let* ((todo-test-home (make-temp-file "todo-test-home-" t))
> + (abbreviated-home-dir nil)
> (process-environment (cons (format "HOME=%s" todo-test-home)
> process-environment))
> (todo-directory todo-test-data-dir)
The only test file that sets abbreviated-home-dir is package-test.el, in
the macro with-package-test, which was indeed the inspiration for
with-todo-test. I assume this would only effect cases like yours, and
hence make the test environment more robust, or are possible problems
that setting it to nil could raise?
>> But when running the tests,
>> sometimes -- but not always -- it fails with the error "`recenter'ing a
>> window that does not display current-buffer." In those cases, the test
>> failure is prevented by evaluating the following sexp immediately before
>> calling todo-toggle-view-done-items:
>>
>> (set-window-buffer nil (current-buffer))
>>
>> When using todo-mode this is not necessary, because the selected window
>> always contains the current buffer when the function is called, but
>> apparently when running the tests, this isn't always the case, although
>> according to Edebug it is, AFAICT.
>
> When I evaluate (selected-window) in edebug before the call, I see
> that the selected window is showing the *ert* buffer.
Yes, I should have checked again before posting that.
>> And again, the failure only happens
>> in some cases, though in those, it is reliably reproducible. In
>> addition, in at least one case, when I rerun the test immediately after
>> it fails, then it succeeds.
>
> I think it succeeds the second time because the *ert* buffer is in a
> different state.
What state is that? In Edebug it appears to be the same as on the first
test run: current-buffer is todo-test-1.todo and selected-window is the
one showing the *ert* buffer, yet now (pos-visible-in-window-p shown) is
non-nil, while on the first run it is nil. I don't see what makes the
difference -- certainly not the value of the variable `shown', which is
226 and that position in window displaying *ert* is visible in both runs.
>> And lastly, in one case, the test succeeds
>> without the set-window-buffer call when run interactively, but fails
>> without it when run in batch mode from the shell. Any idea what's going
>> on here? (If anyone wants to take a closer look, comments in the test
>> file point out the problematic cases.)
>
> todo-test-toggle-item-header04? I added a `message' call, and it seems
> that in batch mode the selected window shows *scratch* whereas in
> interactive mode it shows *ert*. I would say the success in
> interactive mode is just a coincidence.
Well, it's a reliably reproducible coincidence, which seems like a
contradiction in terms.
>> A second problem concerns trying to reference a message in a test. The
>> function todo-toggle-view-done-items outputs a message if the category
>> contains no done items, and the test captures this by calling
>> current-message immediately after todo-toggle-view-done-items. This
>> works when running the test interactively, but in a batch run,
>> current-message is nil (though the message is output in the shell).
>> Why?
>
> I think it's simply that there is no echo-area or any concept of a
> "current" message when running in batch mode.
Yes, as Martin also pointed out; I didn't realize (or stop to think
about) that.
> lread-tests--last-message might be worth looking at:
>
> (defun lread-tests--last-message ()
> (with-current-buffer "*Messages*"
> (save-excursion
> (goto-char (point-max))
> (skip-chars-backward "\n")
> (buffer-substring (line-beginning-position) (point)))))
Thanks for the pointer, and for the feedback.
Steve Berman
next prev parent reply other threads:[~2017-07-08 14:50 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-07 21:22 Some testing issues Stephen Berman
2017-07-08 4:20 ` Noam Postavsky
2017-07-08 14:50 ` Stephen Berman [this message]
2017-07-08 22:01 ` Noam Postavsky
2017-07-14 9:55 ` Stephen Berman
2017-07-08 4:45 ` Stefan Monnier
2017-07-08 14:52 ` Stephen Berman
2017-07-10 17:33 ` Stefan Monnier
2017-07-14 9:56 ` Stephen Berman
2017-07-14 13:44 ` Stefan Monnier
2017-07-17 10:02 ` Stephen Berman
2017-07-17 18:22 ` Stefan Monnier
2017-07-08 7:18 ` martin rudalics
2017-07-08 14:51 ` Stephen Berman
2017-07-09 7:46 ` martin rudalics
2017-07-14 9:55 ` Stephen Berman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87zicfnft7.fsf@rosalinde \
--to=stephen.berman@gmx.net \
--cc=emacs-devel@gnu.org \
--cc=npostavs@users.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).