Bastien <b...@altern.org> writes:
> Eric Schulte <eric.schu...@gmx.com> writes:
>
>> `org-test-for-executable' signals it's own error, but if we
>> changed `org-test-for-executable' to return a boolean and then used your
>> example above it would be more readable.
>
> Perhaps -- what I mean is that if (org-test-for-executable "python")
> signal a missing dependancy, then test-ob-python.el should not be part
> of the testing suite.
>
> Do you see what I mean?
Yes, I think we are already doing exactly what you are suggesting.
Specifically, as each file of tests with external dependencies is loaded
(e.g. test-ob-python.el) the first forms evaluated in that file are
;; -*- emacs-lisp -*-
(org-test-for-executable "python")
(unless (featurep 'ob-python)
(signal 'missing-test-dependency "Support for Python code blocks"))
Thus, if the required executable (in this case python) is not available
on the user's system, or if the user has not loaded ob-python, then a
missing-test-dependency signal will be thrown and none of the tests in
the remainder of the file will be loaded. This ensures that only tests
for which the required executable and Babel code are available will ever
be included in the test suite.
The `org-test-load' function, which loads of all of the test files,
catches these missing-test-dependency signals and for each one it
creates a dummy test that fails but is expected to fail. These tests
serve to indicate to the user that there are tests which are not being
run.
Does this all make sense?
Thanks,
--
Eric Schulte
http://cs.unm.edu/~eschulte
