From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carsten Dominik Subject: Re: Proposal: Emtest as tester Date: Tue, 25 May 2010 08:48:35 +0200 Message-ID: <41A045D3-9A97-4FD8-AF2F-AB2AFE85298E@gmail.com> References: <047c96c5361a8739fc4e8bb94abeef8e.squirrel@mail.panix.com> <736AEF85-4B24-41A0-8701-A2585CBDB4C7@gmail.com> <519bd899d41d1f97d0b7638ad2b702da.squirrel@mail.panix.com> <5F014FD2-5988-406F-9683-ACF2E3096231@gmail.com> <0bbc0d9ab1b84a87a1114077c5d72238.squirrel@mail.panix.com> Mime-Version: 1.0 (Apple Message framework v936) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from [140.186.70.92] (port=52699 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OGoOg-0001Yg-Gr for emacs-orgmode@gnu.org; Tue, 25 May 2010 03:17:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OGoOc-00085U-Bc for emacs-orgmode@gnu.org; Tue, 25 May 2010 03:17:54 -0400 Received: from mail-ww0-f41.google.com ([74.125.82.41]:35530) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OGoOc-00085N-4r for emacs-orgmode@gnu.org; Tue, 25 May 2010 03:17:50 -0400 Received: by wwi14 with SMTP id 14so3272597wwi.0 for ; Tue, 25 May 2010 00:17:48 -0700 (PDT) In-Reply-To: <0bbc0d9ab1b84a87a1114077c5d72238.squirrel@mail.panix.com> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: "Tom Breton (Tehom)" Cc: emacs-orgmode@gnu.org On May 24, 2010, at 11:26 PM, Tom Breton (Tehom) wrote: > At Carsten's request, I am proposing emtest as the tester for > org-mode. I would like to hear if there are any objections or > questions. > > ****** About Emtest > > Emtest is an emacs-based test framework. It reads tests, runs them on > command and presents their results. Test suites can be run by suite, > by clause, or by library. > > It is extensible and modular. Nearly everything about it can be > replaced or extended. > > One important feature is its testhelp libraries: > > * mocks/filebuf - for making mock files and buffers to run tests in. > * mocks/dirtree - for making mock directory trees. > * deep-type-checker - for testing that objects, especially > structures, are type-correct right down to their leaves. > * match - for pattern-matching. When you want to test return values > or similar, but some fields or elements don't have stable values > (say, a timestamp or a UUID). > * tagnames - extremely useful for defining test data and iterating > over examples. > * testpoint - useful for: > 1. testing functionality that is called deep inside something else, > where writing a viable test would mean nearly cloning the > something else to get the calling conditions right. > 2. Testing functionality that uses other functionality that can't > be easily controlled by passing arguments. > 3. Testing that under given circumstances a certain point is > reached, not reached, or reached the right number of times. > > Also, in less than perfect shape right now: > > * mocks/keystuffer - work in progress, for capturing canned user input > * misc and standard - standard testhelp functions. Works but > undergoing reorganization. > * types - type specifications, extending what cl provides. Right > now, just a few that I needed. > * persist - useful for tests of inspected output. Not working right > now due to redesign of an underlying package. > > ****** Some questions > > * Where to include it: > > * I'm proposing to put it under org-mode/testing/ So the directory > structure would look like: > > * org-mode > > * lisp > > * (etc) > > * testing > > * emtest > > * Many files > > * Some support > * packages emtest > * uses. > > * org-agenda > > * tests.el > > * (And other test files) > > * org-archive > > * tests.el > > * org-ascii > > * etc (the other org files' directories of test files) > > * (other existing org directories) > > * Should testing of contrib files be in a separate directory? It's > not clear to me that it needs to be or should be. > > * Loading. > > Of course this shouldn't require much extra work to build and > install. Yet there's a case to be made for not building or > installing it by default, "them that don't use it doesn't pay a > cost". > > So I'm thinking I should add another target to the makefile to > install it, as well as (of course) a test target. Yes, I agree. > > * How to include it, git-wise. > > What git wants to do with included external projects is to make > them submodules. However, I'm told that's a pain to deal with, > moreso from the other end than from mine. And it does seem like it > would be. Basically git treats a submodule as a single thing, but > still "signs" it version-wise with a hex ID, and wants it to be the > correct version. So git insulates you just a little bit, at the > cost of having to deal with an additional repository. > > So I'm thinking I'd just include it literally and if that proves > hard to maintain then we still have the other option. I agree with you. - Carsten