From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Christian Ohler Newsgroups: gmane.emacs.devel Subject: Re: ert.el --- Emacs Lisp Regression Testing Date: Sat, 05 Jan 2008 12:32:45 +0100 Message-ID: <477F6ADD.4000908@fastmail.net> References: <47782302.5000201@fastmail.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1199532977 32687 80.91.229.12 (5 Jan 2008 11:36:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 5 Jan 2008 11:36:17 +0000 (UTC) Cc: emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jan 05 12:36:38 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1JB7KO-0001oP-03 for ged-emacs-devel@m.gmane.org; Sat, 05 Jan 2008 12:36:36 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JB7K1-0005gd-Fb for ged-emacs-devel@m.gmane.org; Sat, 05 Jan 2008 06:36:13 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JB7Ip-00051V-3Z for emacs-devel@gnu.org; Sat, 05 Jan 2008 06:34:59 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JB7Ik-0004zE-FU for emacs-devel@gnu.org; Sat, 05 Jan 2008 06:34:58 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JB7Ik-0004z5-69 for emacs-devel@gnu.org; Sat, 05 Jan 2008 06:34:54 -0500 Original-Received: from out4.smtp.messagingengine.com ([66.111.4.28]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JB7Ig-0004Gs-FC; Sat, 05 Jan 2008 06:34:50 -0500 Original-Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 2FC1F82F40; Sat, 5 Jan 2008 06:34:50 -0500 (EST) Original-Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Sat, 05 Jan 2008 06:34:50 -0500 X-Sasl-enc: Y8R7wkILmjiXK/xnN7PDt6UXWtpOcUy+4ADaPlnu+s2o 1199532889 Original-Received: from kraut.local (unknown [92.226.146.197]) by mail.messagingengine.com (Postfix) with ESMTP id 5373D27AF0; Sat, 5 Jan 2008 06:34:49 -0500 (EST) In-Reply-To: X-detected-kernel: by monty-python.gnu.org: Genre and OS details not recognized. X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:86143 Archived-At: Richard Stallman, 2007-12-31: > ert.el looks very useful. Would you like to contribute it to Emacs? Yes. > One of the things that has held us back from setting up a test suite > in the past is that only a minority of Emacs bugs concern Lisp progrmming. > Most Emacs bugs involve keyboard commands and/or redisplay. This may be true of the core of Emacs, but testing is also important for (third-party) Elisp packages, and they tend to be testable from Elisp. Also, automated testing is not only about bugs. A comprehensive test suite gives you the freedom to modify any part of the code without being afraid that you'll break something without noticing. This makes it easier to add new features or improve the implementation of existing features and will be useful for Emacs, too, even if we only use it for things that can be tested from Elisp. But, yes, we should also try to automate tests that involve input and redisplay. > It occurs to me that M-x term could be used to test for redisplay. > The idea is that you run a sub-Emacs, send it commands, and check what > it displayed (because what it displayed is now in a buffer). Does a significant share of the input/redisplay bugs that occur in a GUI Emacs also occur on the terminal? > It would be terribly slow to do this starting a new sub-Emacs for each > test. So the test framework ought to be designed to do many such tests > with the same sub-Emacs, clearing out whatever is necessary each time. Yes. > I think that an extension to ert.el, for sub-Emacs testing, might make > it easy to define those tests, much as ert.el makes it easy to define > tests of Lisp execution. > > Interested? The first step would be to identify a few bug reports involving input and redisplay that should be reproducible under M-x term and should make good candidates for automation. Then we can look into automating them and try to come up with a general design. I don't think I'm the right person for that first step, though. Christian.