From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Gemini Lasswell Newsgroups: gmane.emacs.bugs Subject: bug#24940: [PATCH] Add should-call, should-not-call, and their tests Date: Mon, 14 Nov 2016 21:52:23 -0800 Message-ID: References: <8337iuhxgu.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1479189236 11296 195.159.176.226 (15 Nov 2016 05:53:56 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 15 Nov 2016 05:53:56 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (darwin) Cc: 24940@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Nov 15 06:53:51 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c6WgC-0005gK-ID for geb-bug-gnu-emacs@m.gmane.org; Tue, 15 Nov 2016 06:53:12 +0100 Original-Received: from localhost ([::1]:44369 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c6WgF-0004i0-PC for geb-bug-gnu-emacs@m.gmane.org; Tue, 15 Nov 2016 00:53:15 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35199) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c6Wg5-0004gS-K0 for bug-gnu-emacs@gnu.org; Tue, 15 Nov 2016 00:53:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c6Wg2-0002YK-GG for bug-gnu-emacs@gnu.org; Tue, 15 Nov 2016 00:53:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:42227) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1c6Wg2-0002YB-Cg for bug-gnu-emacs@gnu.org; Tue, 15 Nov 2016 00:53:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1c6Wg1-0000kA-W4 for bug-gnu-emacs@gnu.org; Tue, 15 Nov 2016 00:53:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Gemini Lasswell Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 15 Nov 2016 05:53:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 24940 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 24940-submit@debbugs.gnu.org id=B24940.14791891692836 (code B ref 24940); Tue, 15 Nov 2016 05:53:01 +0000 Original-Received: (at 24940) by debbugs.gnu.org; 15 Nov 2016 05:52:49 +0000 Original-Received: from localhost ([127.0.0.1]:57626 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c6Wfp-0000jg-6e for submit@debbugs.gnu.org; Tue, 15 Nov 2016 00:52:49 -0500 Original-Received: from aibo.runbox.com ([91.220.196.211]:39031) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c6Wfn-0000jX-1y for 24940@debbugs.gnu.org; Tue, 15 Nov 2016 00:52:47 -0500 Original-Received: from [10.9.9.212] (helo=mailfront12.runbox.com) by bars.runbox.com with esmtp (Exim 4.71) (envelope-from ) id 1c6Wfl-0008Jt-JL; Tue, 15 Nov 2016 06:52:45 +0100 Original-Received: from [207.118.9.65] (helo=rainbow.local) by mailfront12.runbox.com with esmtpsa (uid:179284 ) (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) id 1c6Wff-0003J0-8w; Tue, 15 Nov 2016 06:52:39 +0100 In-Reply-To: <8337iuhxgu.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 14 Nov 2016 17:50:41 +0200") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:125708 Archived-At: Eli Zaretskii writes: > I don't think our test suite should in general test whether some > functions are or aren't called during execution of the > command/function under test. That's because we are not interested in > the fine details of the implementation of the features being tested, > we are interested in whether it does what it's supposed to do. "What > it's supposed to do" means we should test the return values and the > side effects, a.k.a. "the behavior", and not how the code works > internally. I'll modify the tests I've written to focus on "the behavior". > might do the latter. A better way, though perhaps much harder, would > be to test something much more basic that is common to _any_ prompt, > like look in the echo-area or the minibuffer buffers for suitable > text, or maybe even C-level infrastructure that catches the situation > where Emacs waits for user input. I agree that infrastructure to allow a test to set up input to be supplied to the next prompt and to read the prompt message would be a better solution. Keyboard macros work to simulate user input for any test code that isn't trying to test kmacro-step-edit-macro. If there was a hook that the C code could run just prior to taking input from a keyboard macro, tests could use it to check that the correct prompt appears at the correct point in the macro. Such a hook would also be helpful in the attempt to fix kmacro-step-edit-macro's bugs. Mostly where it messes up now is when several input events happen during one command, and a pre-input hook would allow it to inspect keyboard macro execution event by event rather than command by command. The remaining problem that I see is that lots of code in lots of places suppresses messages depending on called-interactively-p, executing-kbd-macro and/or noninteractive, and although that doesn't just affect tests that use keyboard macros, it does make it hard to test how Emacs behaves interactively. > If we can agree that the above use cases are the only ones where such > macros should be used, then these macros should be much leaner than > what you propose, because there should be no need to provide many of > the features in your proposal, like testing the arguments and the > return value, or the number of times the subroutines are called. The leanest version I can think of would be: (with-added-advice BINDINGS BODY) where BINDINGS is a list of argument lists for advice-add. It would call advice-add once for each element of BINDINGS, execute BODY, and then remove all the added advice. Then it looks like something that belongs in nadvice.el instead of ert.el.