[Top][All Lists]

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

Re: call for more ert tests

From: Andreas Röhler
Subject: Re: call for more ert tests
Date: Mon, 01 Jul 2013 13:35:54 +0200
User-agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6

Am 24.06.2013 20:24, schrieb Lennart Borgman:
On Mon, Jun 24, 2013 at 8:21 PM, Eli Zaretskii <address@hidden> wrote:

From: Glenn Morris <address@hidden>
Date: Mon, 24 Jun 2013 13:31:50 -0400

One thing that could help reduce this is more unit tests.
If you haven't used it, ERT makes it pretty easy to write tests.
Of course, many aspects of Emacs's behaviour are not easy to test (GUI
stuff, etc.), but many are. See test/automated/ for examples. [2]

For example, package.el seems like something that should have a test

So if you fix a bug, please consider adding a unit test to make sure it
does not come back. Or if you rewrite a lisp package, consider adding
tests at the same time to check that obvious functionality still works.

I know writing tests is maybe not as interesting as writing shiny new
features, but I think it will save work in the long run.

IMO, unless we require every new feature to come with a test and a
report that no regressions were found by running the existing tests,
we will never get any better testability than what we have now.

Maybe writing tests for all bugs that shows up?

That's good. I'm keeping such a thing for python-mode.el


What's nice about: if some regression occurs, the bug-number leads to the 
reports and helps fixing.

However, IMO a dual system is needed. Having a test for all bugs will be slow 
from a certain amount.
Need to condense that again into some more structured.

BTW as all the tests must not be part of Emacs itself, what about dropping the 
copyright assignment policy, make tests rely on GPL?
AFAIS are a lot of hackers around which might help then.


reply via email to

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