From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: call for more ert tests Date: Tue, 25 Jun 2013 18:15:52 +0300 Message-ID: <83ehbqi5lj.fsf@gnu.org> References: <838v1zjrnl.fsf@gnu.org> <8361x3jqsy.fsf@gnu.org> <8338s7jp53.fsf@gnu.org> <87bo6vb8uo.fsf@wanadoo.es> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1372173379 29557 80.91.229.3 (25 Jun 2013 15:16:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 25 Jun 2013 15:16:19 +0000 (UTC) Cc: emacs-devel@gnu.org To: Lars Magne Ingebrigtsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jun 25 17:16:18 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UrUyc-0006xo-El for ged-emacs-devel@m.gmane.org; Tue, 25 Jun 2013 17:16:14 +0200 Original-Received: from localhost ([::1]:40762 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UrUyc-000094-0X for ged-emacs-devel@m.gmane.org; Tue, 25 Jun 2013 11:16:14 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53036) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UrUyW-00006W-Bl for emacs-devel@gnu.org; Tue, 25 Jun 2013 11:16:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UrUyR-0000i0-BY for emacs-devel@gnu.org; Tue, 25 Jun 2013 11:16:08 -0400 Original-Received: from mtaout23.012.net.il ([80.179.55.175]:36606) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UrUyR-0000hT-3P for emacs-devel@gnu.org; Tue, 25 Jun 2013 11:16:03 -0400 Original-Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0MOY00600FQHMZ00@a-mtaout23.012.net.il> for emacs-devel@gnu.org; Tue, 25 Jun 2013 18:16:01 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MOY006EEFQOB9B0@a-mtaout23.012.net.il>; Tue, 25 Jun 2013 18:16:01 +0300 (IDT) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.175 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:161028 Archived-At: > From: Lars Magne Ingebrigtsen > Date: Tue, 25 Jun 2013 13:06:18 +0200 > > > Eli Zaretskii writes: > >> > >> I believe it's good, obviously. The problem is with introducing it > >> without losing too many contributors. > > I think the bar to contributing to Emacs is high enough as it is without > adding further requirements. I don't know why you are saying this. Please elaborate by comparing with other projects whose bar is significantly lower. For me, the single most important issue for contributing is how easy or hard is it to find the reason for the problem(s) that cause my itch, and how easy or hard is it to make a change that I can convince myself is right. I can tell you that in my experience, Emacs is not much harder in this regard than other projects, like GDB or Guile (to pick just 2 random examples). In any case, I didn't say that we actually should require tests as part of any contribution. All I said was that if we don't, the chances of us getting anywhere with the test suite are extremely low. In fact, I believe that only an appearance of a very dedicated person who would do the job is the only alternative to a strict policy of requiring tests with each changeset. How probable is that such an alternative materializes any time soon, in your opinion? > ert is fine, but, I think, somewhat misguided. It allows us to test the > functions we have Lisp interfaces for, but not the deep internal C > bits. And that's kinda backward. > > When I write Lisp code, I'm testing it interactively all the time. What > should this function return? Does it return what I'm expecting? No? > *hack hack* Now? Yes. Done. I agree that testing C-level internals is a must. But most of Emacs is Lisp code, and if you examine the bug reports, I think you will find that most of them are about Lisp code. So testing Lisp is also important. It's not just the API that is being tested; it's the behavior under different inputs and user options; in short, how well the API keeps its side of the contract.