Re: Some testing issues

[Stephen Berman]

On Sat, 8 Jul 2017 18:01:12 -0400 Noam Postavsky <address@hidden> wrote:

> On Sat, Jul 8, 2017 at 10:50 AM, Stephen Berman <address@hidden> wrote:
>>>    `(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))
>>
>> 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?
>
> abbreviated-home-dir is essentially a cache used by
> abbreviate-file-name, and when the value of HOME is changed the cached
> value is wrong, hence why setting it to nil is the right thing.
> Possibly we should record the value of HOME we cached and clear it
> automatically when a new one is used so that this kind of thing is not
> needed.

In the mean time, it sounds like setting it to nil is appropriate.

>>>
>>> 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.
>
> Maybe the set-window-buffer from the other tests leaks in? For some
> reason I can't reproduce this today, every time I run with the
> set-window-buffer commented out it consistently fails. I'm sure
> yesterday I saw it succeeding after the first time.

There should be no leakage, because the state is cleared after each
individual test run (at least, that's what with-todo-test is supposed to
do).

>>> 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.
>
> I mean "coincidence" in the same way that the 5th digit of pi being 5
> is a "coincidence" (slightly less reliable than that though,
> presumably if we made `initial-scratch-message' long enough the batch
> mode behaviour would change).

Ah, ok.

Steve Berman