unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Christian Ohler <ohler+emacs@fastmail.net>
To: rms@gnu.org
Cc: emacs-devel@gnu.org
Subject: Re: ert.el --- Emacs Lisp Regression Testing
Date: Sat, 05 Jan 2008 12:32:45 +0100	[thread overview]
Message-ID: <477F6ADD.4000908@fastmail.net> (raw)
In-Reply-To: <E1J9Lqt-0007Q8-GH@fencepost.gnu.org>

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.

  reply	other threads:[~2008-01-05 11:32 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-30 23:00 ert.el --- Emacs Lisp Regression Testing Christian Ohler
2007-12-30 23:28 ` Lennart Borgman (gmail)
2008-01-05 11:32   ` Christian Ohler
2007-12-31 14:42 ` Richard Stallman
2008-01-05 11:32   ` Christian Ohler [this message]
2008-01-05 13:06     ` Eli Zaretskii
2008-01-06  8:10       ` Richard Stallman
2008-01-06 19:46         ` Eli Zaretskii
2008-01-07 11:31           ` Richard Stallman
2008-01-07 13:00             ` Mike Mattie
2008-01-03 18:48 ` Phil Hagelberg
2008-01-05 11:32   ` Christian Ohler

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.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=477F6ADD.4000908@fastmail.net \
    --to=ohler+emacs@fastmail.net \
    --cc=emacs-devel@gnu.org \
    --cc=rms@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.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).