From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: phillip.lord@russet.org.uk (Phillip Lord) Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] master 75336a2: Merge branch 'feature/standard-test-location' Date: Sun, 29 Nov 2015 21:15:45 +0000 Message-ID: <87y4dga4n2.fsf@russet.org.uk> References: <20151126211432.7647.1395@vcs.savannah.gnu.org> <5659F8CC.2070106@yandex.ru> <87d1uukk29.fsf@russet.org.uk> <565A0931.8010502@yandex.ru> <874mg5lt2u.fsf@russet.org.uk> <565A7C13.6080807@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1448831779 16503 80.91.229.3 (29 Nov 2015 21:16:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 29 Nov 2015 21:16:19 +0000 (UTC) Cc: emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Nov 29 22:16:07 2015 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 1a39KG-0000OG-Ug for ged-emacs-devel@m.gmane.org; Sun, 29 Nov 2015 22:16:05 +0100 Original-Received: from localhost ([::1]:37736 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a39KL-0007nn-01 for ged-emacs-devel@m.gmane.org; Sun, 29 Nov 2015 16:16:09 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35342) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a39K7-0007nB-W0 for emacs-devel@gnu.org; Sun, 29 Nov 2015 16:15:56 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a39K2-0002wN-Ty for emacs-devel@gnu.org; Sun, 29 Nov 2015 16:15:55 -0500 Original-Received: from cheviot12.ncl.ac.uk ([128.240.234.12]:39519) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a39K2-0002vx-IL for emacs-devel@gnu.org; Sun, 29 Nov 2015 16:15:50 -0500 Original-Received: from smtpauth-vm.ncl.ac.uk ([10.8.233.129] helo=smtpauth.ncl.ac.uk) by cheviot12.ncl.ac.uk with esmtp (Exim 4.63) (envelope-from ) id 1a39Jz-0001Nx-9u; Sun, 29 Nov 2015 21:15:47 +0000 Original-Received: from cpc6-benw10-2-0-cust45.gate.cable.virginm.net ([92.238.179.46] helo=localhost) by smtpauth.ncl.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1a39Jy-0000IO-R5; Sun, 29 Nov 2015 21:15:46 +0000 In-Reply-To: <565A7C13.6080807@yandex.ru> (Dmitry Gutov's message of "Sun, 29 Nov 2015 06:16:19 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 128.240.234.12 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:195574 Archived-At: Dmitry Gutov writes: > On 11/28/2015 11:20 PM, Phillip Lord wrote: > >> In my experience, pulling from master leaves the "automatic" directory >> there, although it's gone from git. I'd expected it to delete when the >> equivalent was removed from git, but apparently not. > > Apparently it's being left there as long as there are some untracked (or > ignored) files inside. Ah okay. So if you make distclean before pulling it would be okay. >> Well, there is a place for manual test material. ERT is good for doing >> unit tests, but some integration tests are likely to remain. But if a >> test is automatable, then I see no reason it should not run. > > Right. But all "manual" tests we have now should be automatable, I think. I'll have a look at this maybe, although I'd prefer the original authors of the tests ported them. >> If we need an indent test location, then I think this would be good to >> support, but it would be nice to have a standard naming scheme. I'd like >> to add support to the make file so that tests (or the .log file) depend >> on the file that they are testing. At the moment, if you edit (for >> example) lisp/calc/calc.el, and then run make check, the calc-tests.el >> file does not get run. This makes no sense to me. The same should be >> true with indentation tests. > > 'make check' runs all tests, doesn't it? Including calc-tests.el. No. make check runs all tests that are not up to date. So, it runs calc-tests.el only if calc-tests.el has been changed. > It would be nice to be able to run the tests corresponding to the > current file only, but Makefile might not be the best place to > implement that. The make file before my changes allowed make calc-tests make calc-tests.log The former dumps output to screen, the latter to file. Now you can do any of: make calc-tests make lisp/calc/calc-tests make lisp/calc/calc-tests.log The make file on feature/tests-depend-on-source also makes tests depend on the source file (based on file name). It uses Emacs to generate a include make file like so: lisp/calc/calc-tests.log: ../lisp/calc/calc.elc lisp/calendar/icalendar-tests.log: ../lisp/calendar/icalendar.elc lisp/emacs-lisp/cl-generic-tests.log: ../lisp/emacs-lisp/cl-generic.elc Seems to work. If you are building Emacs a lot, then you just switch from "make" to "make check" and it runs the relevant tests. At the moment, I think, tests do not get routinely run. The coverage hydra build has been failing on tests for 2 or 3 weeks, for instance. > The .el extension points to emacs-lisp-mode already, doesn't it? Then you are testing two things: auto-mode-alist *and* indentation. >> I hadn't thought of the idea of unindenting first -- I shall add that. > > Actually, having -unindented files seems largely unnecessary to me. I ported > that idea straight from the test suite inside the Ruby core, but the benefits > are relatively small, and that would double the number of files. But hey, we > can try it both ways. No, I agree with you. unindenting first seems generally better to me. >> It's got a "with-temp-buffers" macro also (for when you need several at >> once), and "with-preserved-buffer-list". >> >> Anyway, that package is early days yet. We shall see if it become useful >> as it develops. > > Have you considered just adding a few functions to ert-x? As a first step, I > mean. Not yet, no. I wanted to get something working and useful first. The problem with adding it to ert-x is that it's core, and I think I'd rather have it in ELPA in the short term. Phil