From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Christian Ohler Newsgroups: gmane.emacs.devel Subject: Re: Running ert tests on buffers in rst.el and elsewhere Date: Sat, 23 Jun 2012 00:37:36 +0200 Message-ID: <4FE4F3B0.6070309@gnu.org> References: <6280.1340054412@theowa.merten-home.homelinux.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1340404667 15525 80.91.229.3 (22 Jun 2012 22:37:47 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 22 Jun 2012 22:37:47 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Merten Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jun 23 00:37:47 2012 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 1SiCU5-00008E-UG for ged-emacs-devel@m.gmane.org; Sat, 23 Jun 2012 00:37:46 +0200 Original-Received: from localhost ([::1]:36608 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SiCU5-0000ge-SG for ged-emacs-devel@m.gmane.org; Fri, 22 Jun 2012 18:37:45 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:37111) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SiCU2-0000gZ-Cr for emacs-devel@gnu.org; Fri, 22 Jun 2012 18:37:43 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SiCU0-00007W-DZ for emacs-devel@gnu.org; Fri, 22 Jun 2012 18:37:41 -0400 Original-Received: from fencepost.gnu.org ([208.118.235.10]:43601) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SiCU0-00007R-9a for emacs-devel@gnu.org; Fri, 22 Jun 2012 18:37:40 -0400 Original-Received: from [46.218.212.155] (port=58358 helo=kamel.local) by fencepost.gnu.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1SiCTy-0004At-Rv; Fri, 22 Jun 2012 18:37:39 -0400 In-Reply-To: <6280.1340054412@theowa.merten-home.homelinux.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 208.118.235.10 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:151095 Archived-At: Stefan Merten, 2012-06-18: > I wanted to test functions which operate on buffers - i.e. use buffer > content as input and possibly modify the buffer. Buffer includes point > and mark in this case. Since I found no support for this requirement > in the ert package I wrote some support code for it. I only glanced at your code so far, but please do take a look at the current version of ERT, in particular the utility functions in ert-x.el and the way ert-x-tests.el uses them. Some preliminary notes: Is it true that your code covers two features, one about turning buffer content, point and mark into a data structure and back as well as comparing such data structures, the other about providing input to interactive functions like completing-read? The function `ert-run-test-with-buffer' combines both features, and I don't think that's a good thing; it would be better to have a more primitive function `ert-run-with-interactive-inputs' (or similar) that doesn't do any of the buffer management, and let the programmer combine that function with `ert-with-test-buffer' and `ert-Buf-to-buffer' as appropriate. Similarly, `ert-compare-test-with-buffer' looks like it checks a bunch of things that should probably be left as separate `should' forms on the caller's side. With functions like `ert-equal-buffer', your code introduces a notion of equality of buffers, and its definition seems somewhat arbitrary, so I'm not sure it's a good one. For example, it doesn't take buffer-local variables or markers into account. It should be easy to avoid the question of what the right notion of buffer equality is by letting the programmer extract ert-Buf data structures from buffers and compare those in `should' forms with some equality predicate. However, compared to the existing approach as used in the tests `ert-test-run-tests-interactively-2' and `ert-test-describe-test', your buffer handling functions add the ability to test the position of point and mark, while sacrificing the ability to test text properties (and thus font locking). From a high-level perspective, testing point and mark looks like a small feature on top of testing buffer content, so I'm not sure it justifies as much additional machinery as your code seems to add; we should look for ways to simplify things. As a first step, could make the two features (providing interactive input and handling buffer content) orthogonal and send separate patches, perhaps simplifying the buffer content code after looking at how it's done in ert-x-tests.el? > The next step I considered was to support testing font locking - or > may be text properties in general. However, I didn't start this yet. > It certainly would be useful. ert-x.el does have features related to this, see `ert-propertized-string' and `ert-equal-including-properties'. ERT's self-tests make use of them. Christian.