emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: burden of maintainance


From: Chad Brown
Subject: Re: burden of maintainance
Date: Fri, 2 Oct 2015 12:28:55 -0700

> On 02 Oct 2015, at 11:24, Eli Zaretskii <address@hidden> wrote:
> 
>> From: Tassilo Horn <address@hidden>
>> Cc: Przemysław Wojnowski <address@hidden>,
>>  address@hidden,  address@hidden
>> Date: Fri, 02 Oct 2015 19:18:08 +0200
>> 
>> Eli Zaretskii <address@hidden> 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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]