|
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 suite. 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 http://bazaar.launchpad.net/~python-mode-devs/python-mode/python-mode/view/head:/test/py-bug-numbered-tests.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. Andreas
[Prev in Thread] | Current Thread | [Next in Thread] |