all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Chad Brown <yandros@gmail.com>
To: emacs-devel <emacs-devel@gnu.org>
Cc: Eli Zaretskii <eliz@gnu.org>, Tassilo Horn <tsdh@gnu.org>
Subject: Re: burden of maintainance
Date: Fri, 2 Oct 2015 12:28:55 -0700	[thread overview]
Message-ID: <82C9211A-54C4-40A6-8BF0-2C007875A755@gmail.com> (raw)
In-Reply-To: <837fn55ds7.fsf@gnu.org>


> On 02 Oct 2015, at 11:24, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Tassilo Horn <tsdh@gnu.org>
>> Cc: Przemysław Wojnowski <esperanto@cumego.com>,
>>  andreas.roehler@online.de,  emacs-devel@gnu.org
>> Date: Fri, 02 Oct 2015 19:18:08 +0200
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>>>> Can you give an example? Of course not everything can be tested, but
>>>> many things can.
>>> 
>>> We are mis-communicating again: I meant features which display
>>> something or involve interactive keyboard input.
>> 
>> Emacs is in a better position here than most other tools because it has
>> keyboard macros and can easily inspect the things it displays, e.g., the
>> text properties or overlays at point.
> 
> We may be mis-communicating here.  Because I cannot see how examining
> text properties or overlays can test whether their display on screen
> is correct.  What am I missing?  Can you show an example of what you
> had in mind?

I believe that Tassilo is talking about tests in the vein of “does the buffer report containing the expected characters, in the expected order, with the expected properties, etc”, rather than “are the expected pixels on the display the expected colors at the expected times”. Similarly, tools exist to automate testing with a synthetic mouse and keyboard.

I had some experience with this kind of testing a long while back (roughly, 1995-2000). There are tools that can be used to automate tests of GUIs, but they were (I think still are, but I’m not current) fairly deeply complicated - that is, they use their own fairly extensive language and idiom. It would take significant effort to learn these test harnesses, especially if one wanted to drive them from elisp (unless the SotA has changed more than I think - which is possible).

That said, we found that we could get quite a lot of benefit out of automated testing that basically ignored the gui. I suspect that emacs could see roughly the same - while there are issues that require testing the gui, there are also a great many that don’t. Looking over the recent archives for emacs-devel, it seems like a majority of topics would fall into this “can ignore the gui” category. This might be enough to get emacs started toward a more test-driven development model.

Hope that helps,
~Chad





  parent reply	other threads:[~2015-10-02 19:28 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-01  8:10 burden of maintainance Andreas Röhler
2015-10-01 16:03 ` Eli Zaretskii
2015-10-01 18:46   ` Andreas Röhler
2015-10-01 19:09     ` Eli Zaretskii
2015-10-01 20:18       ` Andreas Röhler
2015-10-01 20:27         ` Eli Zaretskii
2015-10-02 13:54       ` Przemysław Wojnowski
2015-10-02 14:15         ` Eli Zaretskii
2015-10-02 17:18           ` Tassilo Horn
2015-10-02 18:24             ` Eli Zaretskii
2015-10-02 18:47               ` joakim
2015-10-02 19:16               ` Tassilo Horn
2015-10-02 20:53                 ` Eli Zaretskii
2015-10-02 19:28               ` Chad Brown [this message]
2015-10-02  7:51   ` Helmut Eller
2015-10-02  8:47     ` Eli Zaretskii
2015-10-02  8:56       ` Helmut Eller
2015-10-02  8:59         ` Eli Zaretskii
2015-10-02 11:46         ` Michael Albinus
2015-10-02 11:58   ` Phillip Lord
2015-10-02 13:14     ` Artur Malabarba
2015-10-02 13:36     ` Eli Zaretskii
2015-10-02 15:00       ` Andreas Röhler
2015-10-02 15:16         ` Eli Zaretskii
2015-10-02 17:19           ` Andreas Röhler
2015-10-02 18:08             ` Eli Zaretskii
2015-10-02 18:54               ` Andreas Röhler
2015-10-02 20:39                 ` Tassilo Horn
2015-10-03  6:53                   ` Andreas Röhler
2015-10-03  7:31                     ` Tassilo Horn
2015-10-03  1:38             ` Richard Stallman
2015-10-03  0:38       ` Eric Ludlam
2015-10-02 23:24     ` Xue Fuqiao
2015-10-03  6:42       ` Przemysław Wojnowski
2015-10-03  7:00         ` Xue Fuqiao
2015-10-03  7:15         ` Eli Zaretskii
2015-10-01 16:34 ` Przemysław Wojnowski
2015-10-02 11:25   ` Phillip Lord
2015-10-02 12:27     ` Michael Albinus
2015-10-02 14:53       ` Phillip Lord
2015-10-02 16:56         ` Michael Albinus
2015-10-03  1:35     ` Richard Stallman

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=82C9211A-54C4-40A6-8BF0-2C007875A755@gmail.com \
    --to=yandros@gmail.com \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=tsdh@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.