all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Przemysław Wojnowski" <esperanto@cumego.com>
To: Richard Stallman <rms@gnu.org>
Cc: emacs-devel@gnu.org, stephen_leake@stephe-leake.org,
	Phillip Lord <phillip.lord@russet.org.uk>
Subject: Re: UI tests
Date: Sun, 15 Nov 2015 13:14:28 +0100	[thread overview]
Message-ID: <878u5zjw7v.fsf@cumego.com> (raw)
In-Reply-To: <E1ZwYnS-00056V-Fc@fencepost.gnu.org> (Richard Stallman's message of "Wed, 11 Nov 2015 12:02:58 -0500")

Richard Stallman <rms@gnu.org> writes:
> Unlike the typical graphical applications, Emacs's UIs are mostly
> controlled by events that have a very shallow translation to Lisp
> data.  Even mouse clicks can be faked, and a convenient Lisp function
> to make that totally easy would not be hard to write.
>
> Perhaps the input side of testing UI features will be fairly easy.
>
> The output side is not so straightforward, but if we set up something
> to accumulate a sort of dribble record of X11 output operations, in
> the form of Lisp-visible data, maybe tests could check that to see
> if they have changed from before.

I'm not sure what do you mean by "output side" here?

My understanding is that inputs and outputs are on system's boundaries
and isolate system's functionality using stable interfaces (common in
different architectural pattern - e.g. [1], [2]).

In Emacs, as you wrote, user actions can be faked and that can be used
in tests.

The other side - the outputs - is not that clear to me. Usually the
outputs are hidden under stable interfaces. The interfaces allow to
exchange implementations without affecting the system and the boundary
is used to test the output of the system. In case of display output,
this won't allow to test every single pixel (so no X11 output), but at
least it will allow to test that the system produces correct output for
display, no matter what that display (its underlying library) is.

Two things to note when introducing automated tests:
1. Tests pyramid [3] - indicates which tests are most important and
ratio between them. TL;DR Emacs should focus on unit tests.

2. Ice Cream Cone anti-pattern [3,4] is a common trap for existing
projects that start to add automated tests.

[1] Layers in "Pattern Oriented Software Architecture vol 1"
[2] http://alistair.cockburn.us/Hexagonal+architecture
[3] http://googletesting.blogspot.co.uk/2015/04/just-say-no-to-more-end-to-end-tests.html
(from "The True Value of Tests")
[4] http://watirmelon.com/2012/01/31/introducing-the-software-testing-ice-cream-cone/



  parent reply	other threads:[~2015-11-15 12:14 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-04 17:36 Locations of Tests Phillip Lord
2015-11-04 17:53 ` John Wiegley
2015-11-04 18:14   ` Artur Malabarba
2015-11-04 18:21     ` John Wiegley
2015-11-25  9:23       ` Phillip Lord
2015-11-25  9:43         ` Artur Malabarba
2015-11-25 14:17           ` Phillip Lord
2015-11-04 19:15     ` Steinar Bang
2015-11-04 19:23       ` David Kastrup
2015-11-04 21:33         ` Phillip Lord
2015-11-04 19:07   ` Michael Albinus
2015-11-04 19:15     ` John Wiegley
2015-11-04 21:26       ` Phillip Lord
2015-11-05 13:41         ` Stephen Leake
2015-11-05 13:59           ` Artur Malabarba
2015-11-05 15:02             ` Nicolas Petton
2015-11-05 15:08               ` Artur Malabarba
2015-11-06  9:56                 ` Phillip Lord
2015-11-05 15:27           ` Juanma Barranquero
2015-11-06  9:55           ` Phillip Lord
2015-11-06 10:02 ` Makefile-help (was Re: Locations of Tests) Phillip Lord
2015-11-07  6:48   ` Stephen Leake
2015-11-07 10:55     ` Location of tests (again) (was Re: Makefile-help) Phillip Lord
2015-11-07 11:06       ` Juanma Barranquero
2015-11-07 11:22         ` Phillip Lord
2015-11-07 11:36           ` Juanma Barranquero
2015-11-07 17:46             ` Phillip Lord
2015-11-07 11:45           ` Eli Zaretskii
2015-11-07 18:09             ` Stephen Leake
2015-11-10 20:34       ` Przemysław Wojnowski
2015-11-10 20:45         ` Phillip Lord
2015-11-10 21:41           ` Przemysław Wojnowski
2015-11-10 22:27             ` John Wiegley
2015-11-11  0:28             ` bikeshedding (was Re: Location of tests (again) (was Re: Makefile-help)) Stephen Leake
2015-11-11 10:31             ` Location of tests (again) (was Re: Makefile-help) Phillip Lord
2015-11-11 17:02               ` UI tests Richard Stallman
2015-11-11 17:25                 ` John Wiegley
2015-11-12 14:09                 ` Phillip Lord
2015-11-12 14:37                   ` Alan Mackenzie
2015-11-12 16:33                   ` Eli Zaretskii
2015-11-13 21:58                   ` Richard Stallman
2015-11-15 12:14                 ` Przemysław Wojnowski [this message]
2015-11-16 19:32                   ` 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=878u5zjw7v.fsf@cumego.com \
    --to=esperanto@cumego.com \
    --cc=emacs-devel@gnu.org \
    --cc=phillip.lord@russet.org.uk \
    --cc=rms@gnu.org \
    --cc=stephen_leake@stephe-leake.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.