FTR, I'm just commenting based on experience with a testing harness for
a completely unrelated piece of software.
Achim Gratz writes:
> Eric Schulte 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
Eric Schulte 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 clean
Achim Gratz writes:
> Eric Schulte writes:
>> It will be up to the authors of individual tests to remove tangled and
>> exported files. Ideally we can patch each test to clean up after
>> itself. Perhaps we should provide a test macro which accepts a list of
>> file names and optionally remove
Eric Schulte writes:
> It will be up to the authors of individual tests to remove tangled and
> exported files. Ideally we can patch each test to clean up after
> itself. Perhaps we should provide a test macro which accepts a list of
> file names and optionally removes them if the test exists su
Achim Gratz writes:
> Olaf Meeuwissen writes:
>> Successful tests can clean up after themselves but failed tests should
>> not so you can debug. The decision to remove these files should be left
>> to whoever runs the test suite. That implies that even successful tests
>> don't really have to
Achim Gratz writes:
> Barring any setup or options I might have missed, it looks like I will
> have to do two things: first, set TMPDIR to a newly created directory
> during the test runs and second, remove that directory after the test
> (with an option to keep it for inspection and removing only
Olaf Meeuwissen writes:
> Successful tests can clean up after themselves but failed tests should
> not so you can debug. The decision to remove these files should be left
> to whoever runs the test suite. That implies that even successful tests
> don't really have to bother cleaning up after the
Achim Gratz writes:
> Olaf Meeuwissen writes:
>> If running `make check` (or similar) creates these files, `make clean`
>> (or similar) should clean them up.
>
> I was asking that question to decide whether I do need to extend my
> Makefile fork to handle the cleanup or if the testsuite needs to
Brian Wightman writes:
> Files created in the system $TMPDIR are not meant (caution: purist
> view) to remain beyond the execution of the program (or set of
> programs).
You are preaching to the choir... :-)
I'm still looking for some wisdom regarding the actual testsuite setup
in orgmode, thoug
On Wed, Feb 15, 2012 at 11:11 AM, Achim Gratz wrote:
> Olaf Meeuwissen writes:
>> If running `make check` (or similar) creates these files, `make clean`
>> (or similar) should clean them up.
>
> I was asking that question to decide whether I do need to extend my
> Makefile fork to handle the clea
Olaf Meeuwissen writes:
> If running `make check` (or similar) creates these files, `make clean`
> (or similar) should clean them up.
I was asking that question to decide whether I do need to extend my
Makefile fork to handle the cleanup or if the testsuite needs to be
called differently to avoid
Achim Gratz writes:
> I've started to always test each build. It seems that the temporary
> files from testing (they end up in /tmp) are not actually removed after
> testing and continue to pile up. Is there an option that I might have
> missed that prevents these files from being removed or sh
12 matches
Mail list logo
