From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dan Davison Subject: Re: Proposal: Emtest as tester Date: Mon, 24 May 2010 18:56:52 -0400 Message-ID: <87k4qs7vt7.fsf@stats.ox.ac.uk> 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 Content-Type: text/plain; charset=us-ascii Return-path: Received: from [140.186.70.92] (port=50087 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OGgZz-0003KK-EC for emacs-orgmode@gnu.org; Mon, 24 May 2010 18:57:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OGgZu-0003bp-5I for emacs-orgmode@gnu.org; Mon, 24 May 2010 18:57:03 -0400 Received: from markov.stats.ox.ac.uk ([163.1.210.1]:38503) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OGgZt-0003bP-Ut for emacs-orgmode@gnu.org; Mon, 24 May 2010 18:56:58 -0400 In-Reply-To: <0bbc0d9ab1b84a87a1114077c5d72238.squirrel@mail.panix.com> (Tom Breton's message of "Mon, 24 May 2010 17:26:51 -0400") 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, Carsten Dominik "Tom Breton (Tehom)" writes: > 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. Hi Tom, My googling didn't manage to find emtest -- where does the code live at the moment? Is there an Org repo out there demonstrating how it would integrate, and/or some documentation and examples of usage? Dan > > ****** 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. > > * 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. > > > Tom Breton (Tehom) > > > > _______________________________________________ > Emacs-orgmode mailing list > Please use `Reply All' to send replies to the list. > Emacs-orgmode@gnu.org > http://lists.gnu.org/mailman/listinfo/emacs-orgmode