[Python-Dev] Tests failing on Windows with TESTFN

[Tim Golden]

On 30/07/2018 16:41, Nick Coghlan wrote:
> On 29 July 2018 at 03:20, Tim Golden <mail at timgolden.me.uk> wrote:
>> I think that was my starting point: rather than develop increasingly
>> involved and still somewhat brittle mechanisms, why not do what you'd
>> naturally do with a new test and use tempfile? I was expecting someone to
>> come forward to highlight some particular reason why the TESTFN approach is
>> superior, but apart from a reference to the possibly cost of creating a new
>> temporary file per test, no-one really has.
> 
> For higher level modules, "just use tempfile to create a new temporary
> directory, then unlink it at the end" is typically going to be a good
> answer (modulo the current cleanup issues that Jeremy is reporting,
> but ideally those will be fixed rather than avoided, either by
> improving the way the module is being used, or fixing any underlying
> defects).
> 
> For lower level modules though, adding a test suite dependency on
> tempfile introduces a non-trivial chance of adding an operational
> dependency from a module's test suite back to the module itself. When
> that happens, module regressions may show up as secondary failures in
> tempfile that then need to be debugged, rather than as specific unit
> test failures that point you towards exactly what you broke.
> 
> Cheers,
> Nick.
> 

Thanks Nick; I hadn't thought about the possible interdependency issue.

I think for the moment my approach will be to switch to support.unlink 
wherever possible to start with. Before introducing other (eg tempfile) 
changes, this should at least narrow the issues down. I've made a start 
on that (before inadvertently blowing away all the changes since my 
hours-previous commit!)

If further changes are necessary then I'll probably look case-by-case to 
see whether a tempfile or some other solution would help.

That said, that's potentially quite a lot of change -- at least in terms 
of files changed if not strictly of functionality. So I'm thinking of 
trickle-feeding the changes through as people will understandably baulk 
at a patchbomb (PR-bomb?) hitting the codebase all at once.

TJG