[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] Temp files from testing are permanent...

From: Olaf Meeuwissen
Subject: Re: [O] Temp files from testing are permanent...
Date: Mon, 20 Feb 2012 09:11:29 +0900
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux)

FTR, I'm just commenting based on experience with a testing harness for
a completely unrelated piece of software.

Achim Gratz <address@hidden> writes:

> Eric Schulte <address@hidden> writes:
>> I should have been more clear.  I'm thinking that this would be a macro
>> used /within/ unit tests so that testers could specify what files will
>> be created (test writers should be able to predict the file names
>> created by their tests) and then the macro will handle cleanup.

Test writers can predict/choose the file names created by their tests
but they cannot predict the file names creates by other test writers'
tests (or their own tests written two weeks ago ;-).  Unless there is
some naming policy that is strictly adhered to, the chance of collisions
remains.  One approach that has worked for me is to have tests create
their outputs in a directory named after the test.  So if I have a test
implemented in test.el, it would create all outputs in test.out/, for
example.  As I put all my tests and their inputs in a tests/ directory
(and nothing else), I can just `rm -rf *.out` there to clean up.

> I'm sitting on the fence with this.  Running the tests from the Makefile
> it would probably be more difficult to ensure that one could keep the
> files when the tests were trying to clean up after themselves (as some
> option would need to be injected into the test invocation and/or a
> different test command would need to be called).

Personally, I prefer to have `make clean` take care of cleaning up my
test outputs.  I control when it gets run, can move valuable stuff out
of the way before doing so and none of the tests have to bother with
conditionalized clean up.

>> I do like the idea of a single directory in which all output files may
>> be collected.  The only potential downside I see for this is that files
>> will be generated both from within org files in the testing/examples
>> directory as well as temporary files.
> The temporary files could be in a sub-directory... or each test (group)
> could have their own sub-directory.  Whatever the organisation, there
> should be a single directory which, if recursively removed, gets rid of
> all files created by the test run.

See above.

Hope this helps,
Olaf Meeuwissen, LPIC-2           FLOSS Engineer -- AVASYS CORPORATION
FSF Associate Member #1962               Help support software freedom

reply via email to

[Prev in Thread] Current Thread [Next in Thread]