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.
next prev parent 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
* 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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.