Re: Some testing issues

[Noam Postavsky <npostavs@users.sourceforge.net>]

On Sat, Jul 8, 2017 at 10:50 AM, Stephen Berman <stephen.berman@gmx.net> 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.

>>
>> 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.

>> 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).