On 14/02/2019 15:24, Giampaolo Rodola' wrote: > > > On Thu, Feb 14, 2019 at 4:03 PM Tim Golden <mail at timgolden.me.uk > <mailto:mail at timgolden.me.uk>> wrote: > > On 14/02/2019 14:56, Giampaolo Rodola' wrote: > > > > > > On Thu, Feb 14, 2019 at 3:25 PM Eric Snow > <ericsnowcurrently at gmail.com <mailto:ericsnowcurrently at gmail.com> > > <mailto:ericsnowcurrently at gmail.com > <mailto:ericsnowcurrently at gmail.com>>> wrote: > > > > On Thu, Feb 14, 2019, 02:47 Ronald Oussoren via Python-Dev > > <python-dev at python.org <mailto:python-dev at python.org> > <mailto:python-dev at python.org <mailto:python-dev at python.org>> wrote: > > > > > > I usually use shutil.rmtree for tests that need to create > > temporary files, and create a temporary directory for those > > files (that is, use tempfile.mkdtemp in setUp() and use > > shutil.rmtree in tearDown()). That way I don’t have to adjust > > house-keeping code when I make changes to test code. > > > > > > Same here. > > > > -eric > > > > > > What I generally do is avoid relying on tempfile.mkdtemp() and > always > > use TESTFN instead. I think it's cleaner as a pradigm because > it's an > > incentive to not pollute the single unit tests with > `self.addCleanup()` > > instructions (the whole cleanup logic is always supposed to occur in > > setUp/tearDown): > > Must chime in here because I've been pushing (variously months & years > ago) to move *away* from TESTFN because it generates numerous > intermittent errors on my Windows setup. I've had several goes at > starting to do that but a combination of my own lack of time plus some > people's reluctance to go that route altogether has stalled the thing. > > I'm not sure I understand the difference in cleanup/teardown terms > between using tempfile and using TESTFN. The objections I've seen from > people (apart, obviously, from test churn) are to do with building up > testing temp artefacts on a possibly low-sized disk. > > TJG > > > I suppose you mean the intermittent failures are usually due to "file is > already in use by another process" correct? test.support's unlink(), Occasionally (and those are usually down to a poorly-handled cleanup). More commonly it's due to residual share-delete handles on those files, probably from indexing & virus checkers or TortoiseXXX cache handlers. Obviously I can (and to some extent do) try to mitigate those issues. In short: reusing the same filepath over and over for tests which are run in quick succession doesn't seem like a good idea usually. That's commonly what TESTFN-based tests do (some do; some don't). I'm 100% with you on strict clean-up, not leaving testing turds behind, not over-complicating simple tests with lost of framework. All that. But -- however it's done -- I'd prefer to move away from the test-global TESTFN approach. I'm not at my dev box atm so can't pick out examples but I definitely have some :) I have no issue with your proposal here: better and simpler cleanup is A Good Thing. But it won't solve the problem of re-using the same test filepath again and again. TJG
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4