On 14/02/2019 15:24, Giampaolo Rodola' wrote:
On Thu, Feb 14, 2019 at 4:03 PM Tim Golden <m...@timgolden.me.uk
<mailto:m...@timgolden.me.uk>> wrote:
On 14/02/2019 14:56, Giampaolo Rodola' wrote:
>
>
> On Thu, Feb 14, 2019 at 3:25 PM Eric Snow
<ericsnowcurren...@gmail.com <mailto:ericsnowcurren...@gmail.com>
> <mailto:ericsnowcurren...@gmail.com
<mailto:ericsnowcurren...@gmail.com>>> wrote:
>
> On Thu, Feb 14, 2019, 02:47 Ronald Oussoren via Python-Dev
> <python-dev@python.org <mailto:python-dev@python.org>
<mailto:python-dev@python.org <mailto:python-dev@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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
