From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Noah Lavine Newsgroups: gmane.emacs.devel Subject: Re: call for more ert tests Date: Tue, 25 Jun 2013 09:33:15 -0400 Message-ID: References: <838v1zjrnl.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7b86ca727a897e04dffa936d X-Trace: ger.gmane.org 1372167241 19484 80.91.229.3 (25 Jun 2013 13:34:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 25 Jun 2013 13:34:01 +0000 (UTC) Cc: Eli Zaretskii , Emacs development discussions To: Glenn Morris Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jun 25 15:34:02 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 1UrTNg-0005pb-5o for ged-emacs-devel@m.gmane.org; Tue, 25 Jun 2013 15:34:00 +0200 Original-Received: from localhost ([::1]:57813 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UrTNf-0005Ac-EN for ged-emacs-devel@m.gmane.org; Tue, 25 Jun 2013 09:33:59 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48350) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UrTNY-0005AV-4R for emacs-devel@gnu.org; Tue, 25 Jun 2013 09:33:57 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UrTNW-0003Y0-Qx for emacs-devel@gnu.org; Tue, 25 Jun 2013 09:33:52 -0400 Original-Received: from mail-pa0-x233.google.com ([2607:f8b0:400e:c03::233]:37752) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UrTNJ-0003Vr-JO; Tue, 25 Jun 2013 09:33:37 -0400 Original-Received: by mail-pa0-f51.google.com with SMTP id lf11so12508706pab.24 for ; Tue, 25 Jun 2013 06:33:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=+o6s+WMk/q+tJy8M3ZfrvR7BWaR6qTp768huZ15p8a8=; b=MdKtf1u5qixgfx3GRlYLmcNQQa183rzeqWjWtgo5POceaJLv+AMeriRtOP1RfCHf0C qaeKeALE9oolrbDvi/ZxXoApV3T9witZE4CamrOXE1aDrf4aabbRb4obn1JHQoyYALIo LjPQtqmsOstNWfsnJtsQDbay93yMdvuOmT6Dbbdp0I7W6lGhhT4wc1hRrfTE3dH5vqPW 0Ujw+kxTdB2Dkyx7eoabkLSkxLmd1eNnVjtWtq+LCZ587PqeyeKQAyiCd7JOHkxfCdZZ lzC76Z3UO8HhV03TTRxnw+B9LGkcR6zZIBHMRMAd8HjRrtR4+IaK6h7Nt+QyZoqh/7Kc uQbw== X-Received: by 10.66.158.9 with SMTP id wq9mr32605336pab.189.1372167215940; Tue, 25 Jun 2013 06:33:35 -0700 (PDT) Original-Received: by 10.68.91.1 with HTTP; Tue, 25 Jun 2013 06:33:15 -0700 (PDT) In-Reply-To: X-Google-Sender-Auth: 8m6e1-mGuREWb8AM1o-cV3NW4Yg X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:400e:c03::233 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:161024 Archived-At: --047d7b86ca727a897e04dffa936d Content-Type: text/plain; charset=ISO-8859-1 I'm afraid I probably won't have time to do this myself, but one idea I've heard is to use Emacs' interactivity to make testing easier. For instance, you could code in a split-window view where one window has your code and another has test results that are constantly updated to match the code. It would be even better if Emacs could figure out how to test on "representative" inputs itself, but I can't figure out how to do that. It seems like quite a hard problem in general, so it would probably on work in some cases. Best, Noah Lavine On Mon, Jun 24, 2013 at 12:46 PM, Glenn Morris wrote: > Eli Zaretskii wrote: > > > 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. > > I think that is a tough goal, and also somewhat pessimistic ("unless we > force everybody to be in complete compliance with X, we will never get > any more X"). Maybe we could try to move gradually in this direction > until it naturally becomes the accepted convention? But maybe you are > right and incremental improvement is impossible. I guess we will see... > > --047d7b86ca727a897e04dffa936d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I'm afraid I probably won't have time to= do this myself, but one idea I've heard is to use Emacs' interacti= vity to make testing easier.

For instance, you could code in a split= -window view where one window has your code and another has test results th= at are constantly updated to match the code.

It would be even better if Emacs could figure out how to test on = "representative" inputs itself, but I can't figure out how to= do that. It seems like quite a hard problem in general, so it would probab= ly on work in some cases.

Best,
Noah Lavine


=
On Mon, Jun 24, 2013 at 12:46 PM, Glenn Morris <= span dir=3D"ltr"><rgm@g= nu.org> wrote:
Eli Zaretskii wrote:

> 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.

I think that is a tough goal, and also somewhat pessimistic ("un= less we
force everybody to be in complete compliance with X, we will never get
any more X"). Maybe we could try to move gradually in this direction until it naturally becomes the accepted convention? But maybe you are
right and incremental improvement is impossible. I guess we will see...


--047d7b86ca727a897e04dffa936d--