[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Add condition-case handler to ert test runner
From: |
Richard H Lee |
Subject: |
Re: Add condition-case handler to ert test runner |
Date: |
Tue, 07 May 2013 02:28:50 +0100 |
User-agent: |
Mozilla/5.0 (Windows NT 6.0; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 |
On 06/05/2013 15:30, Davis Herring wrote:
If that's what you want...
Sorry I probably didn't illustrate how ert works properly.
The way ert catches the signals it generates is by setting
debug-on-error to t and debugger to ert--run-test-debugger, which is its
own custom debugger. ert--run-test-debugger then records the result of
the test according to the signal thrown.
So I'm not trying to invoke the debugger. ert itself invokes its
debugger and always expects it to be invoked upon test failure. And this
is where the problem lies. In the case where ert happens to be called
from within a condition-case with matching handler, ert's debugger will
not be invoked, so the result will not be recorded. ert interprets this
as a test abort and so will not execute any more tests.
...you surely instead want
(condition-case nil
(funcall (ert-test-body (ert--test-execution-info-test
test-execution-info)))
(error (debug))))))
This invokes emacs' standard debugger not ert's ert--run-test-debugger .
By having both error and debug in the handler clause ensures that the
signal (error ert-test-failed) is caught and whatever is assigned to the
variable debugger is called.
And the only way anyone could have figured out how to do this is from
poking around eval.c . Hence my remark about the documentation.
The real question is why ERT's signals are reaching IELM if the latter
invoked the former (whose handlers should thus be innermost).
The answer to this is because ert does not set up a watertight handler
around the execution of the test. My patch fixes this.
Richard