From: Olaf Meeuwissen <olaf.meeuwissen@avasys.jp>
To: emacs-orgmode@gnu.org
Subject: Re: Temp files from testing are permanent...
Date: Mon, 20 Feb 2012 09:11:29 +0900 [thread overview]
Message-ID: <87zkcee53i.fsf@avasys.jp> (raw)
In-Reply-To: <87liny21s1.fsf@Rainer.invalid> (Achim Gratz's message of "Sun, 19 Feb 2012 18:03:58 +0100")
FTR, I'm just commenting based on experience with a testing harness for
a completely unrelated piece of software.
Achim Gratz <Stromeko@nexgo.de> writes:
> Eric Schulte <eric.schulte@gmx.com> 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
http://www.fsf.org/jf?referrer=1962
prev parent reply other threads:[~2012-02-20 0:11 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-14 18:31 Temp files from testing are permanent Achim Gratz
2012-02-14 23:12 ` Olaf Meeuwissen
2012-02-15 17:11 ` Achim Gratz
2012-02-15 18:02 ` Brian Wightman
2012-02-15 18:38 ` Achim Gratz
2012-02-16 20:47 ` Achim Gratz
2012-02-16 0:54 ` Olaf Meeuwissen
2012-02-16 18:14 ` Achim Gratz
2012-02-18 17:46 ` Eric Schulte
2012-02-18 18:48 ` Achim Gratz
2012-02-19 16:21 ` Eric Schulte
2012-02-19 17:03 ` Achim Gratz
2012-02-20 0:11 ` Olaf Meeuwissen [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87zkcee53i.fsf@avasys.jp \
--to=olaf.meeuwissen@avasys.jp \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).