From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Merten Newsgroups: gmane.emacs.devel Subject: Re: Running ert tests on buffers in rst.el and elsewhere Date: Mon, 25 Jun 2012 12:06:22 +0200 Message-ID: <8202.1340618782@theowa.merten-home.homelinux.org> References: <6280.1340054412@theowa.merten-home.homelinux.org> <4FE4F3B0.6070309@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" X-Trace: dough.gmane.org 1340646969 16690 80.91.229.3 (25 Jun 2012 17:56:09 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 25 Jun 2012 17:56:09 +0000 (UTC) Cc: emacs-devel@gnu.org To: Christian Ohler Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jun 25 19:56:07 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 1SjDW3-0000aH-UT for ged-emacs-devel@m.gmane.org; Mon, 25 Jun 2012 19:56:00 +0200 Original-Received: from localhost ([::1]:44085 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SjDW3-0002Is-Qz for ged-emacs-devel@m.gmane.org; Mon, 25 Jun 2012 13:55:59 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:49118) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SjDW0-0002Il-6E for emacs-devel@gnu.org; Mon, 25 Jun 2012 13:55:57 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SjDVy-0001wx-2v for emacs-devel@gnu.org; Mon, 25 Jun 2012 13:55:55 -0400 Original-Received: from moutng.kundenserver.de ([212.227.126.186]:61224) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SjDVx-0001wM-KW; Mon, 25 Jun 2012 13:55:53 -0400 Original-Received: from theowa.merten-home.homelinux.org ([109.46.39.75]) by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis) id 0MOCQe-1SojIH2w0y-006J6y; Mon, 25 Jun 2012 19:55:50 +0200 Original-Received: by theowa.merten-home.homelinux.org (Postfix, from userid 1000) id CB838401DD; Mon, 25 Jun 2012 12:06:22 +0200 (CEST) Original-Received: from theowa.merten-home.homelinux.org (localhost [127.0.0.1]) by theowa.merten-home.homelinux.org (Postfix) with ESMTP id C8B657A009; Mon, 25 Jun 2012 12:06:22 +0200 (CEST) In-reply-to: <4FE4F3B0.6070309@gnu.org> Comments: In-reply-to Christian Ohler message dated "Sat, 23 Jun 2012 00:37:36 +0200." X-Mailer: MH-E 8.2; nmh 1.3; GNU Emacs 23.1.1 X-Provags-ID: V02:K0:68NmakGiSJvwgDgsWsux1T/lO4Ww7j9edYam7amJ7zu vc0c6NfTwwl0WFneKuuqCTS+R4v4kMDZdsSTG7zuaivMuCMvhy bE3FlYItetjnG0wj26V2OJ0q+ms6ZKxWuiaTL6k5zMBbn2x0OI d1qfhS42RM2vYNcwAmRns2b1r3R2fEJOlX3NuE/8ywt7Vxgoys Rk0ON5bw90L9x2H400w6npheUvi9s4RUV0Lci7OqX6vSc18u7x ZB9v6GrxcqDMKs/mfU1kVfpMKpk3yQdq5kBvdEFC3OZYLJ7lDe 9JzOupYZHxBbyxlP25mm3BDV9ZPc52r+XfNRB8m0YAa+Nrzeo7 IjM5zWyGhr7GbZby8gRw0ap7geW6EtcA7QDaQXCxrw96mt1fQy 8uwV1xPfN9McE8Bu3R10i9EFHQsuVsmXLU= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 212.227.126.186 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:151163 Archived-At: --=-=-= Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi Christian! I read your mail just now. 2 days ago Christian Ohler wrote: > 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. >=20 > 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. I just did. Well, I probably did not give enough documentation in the first place to understand what ert-buffer.el should be good for: Give the user an *easy* way to define input buffer and expected output buffer for a test. That's what `ert-equal-buffer' and `ert-equal-buffer-return' is for. Part of this is that the user can give strings describing the buffer so you can write comprehensible tests like (should (ert-equal-buffer (insert "foo") "\^@\^?" "\^?foo\^@")) Once you understood that ?\^@ stands for point and ?\^? stands for mark the meaning of the test is immediately clear. This supports the idea that a test also serves as a documentation for the respective function. I find no support for this idea in ert-x.el but I may miss something. > Some preliminary notes: >=20 > 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, Yes - in a preliminary way though. > the other about providing input to > interactive functions like completing-read? The idea is to give a *simple* framework to test function calls which operate on buffers. This includes interactive function calls which may request further input from the user. That is why I implemented the advices to the reading functions. > 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. It could be useful to separate this feature more clearly to make it reusable in other situations. However, for testing interactive functions on buffers - which to me seems a quite natural thing to do - it should stay a feature of `ert-equal-buffer' / `ert-equal-buffer-return'. > 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. Same as above. > 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. True. It's just what I needed for my own tests. This is certainly an aspect which deserves more work. > For example, it doesn't take > buffer-local variables or markers into account. Yes. I already thought about this. As mentioned above one design goal of ert-buffer.el was simplicity for the user. Thus the user needs a simple syntax to write a buffer contents for a test. I used ?\^@ and ?\^? as simple syntax for point and mark which at the same time should not collide with real input. What could an extension to this syntax including markers and text properties look like? For text properties I thought of something like ?\^[ and ?\^] as delimiters and some content describing the properties between the delimiters. May be plain lisp forms? > 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. I agree that the programmer should have a chance to define her own equality but there should be a reasonable default. > 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; Not if you test a function like `insert' which has a clear contract on how point and mark is treated. I guess this applies to the majority of functions which operate on buffers. > we should look for ways to simplify things. Indeed. However, my notion of simplicity seems to differ from yours. > 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? I will give it a try. >> 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. >=20 > 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. I'll look at it. Gr=FC=DFe Stefan --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQCVAwUBT+g4HgnTZgC3zSk5AQLpEwQAghH858C+fjgTmypktSqb78ERlo29NJeO Me1N0cK2Z9DbvIUQXPp1N8foDJ0gcdubhymrP17N4yNPi1pIicpSta8lU9YPmJo1 zODxnSbUWv3o5oCVPWLvKr+xI4zjwXVr8c+CLTMA23QFUPFmApqsXxvN1lTBs8KF zK9k5clFAu4= =gnsC -----END PGP SIGNATURE----- --=-=-=--