[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: testing framework and package.el

From: Christian Ohler
Subject: Re: testing framework and package.el
Date: Wed, 13 Oct 2010 21:00:37 +1100

 On 13/10/10 4:58, Stephen J. Turnbull wrote:
Christian Ohler writes:

  >  I see, thanks for clarifying.  Is it really mainly ELisp language
  >  features where this applies?

It applies to everything in the Lispref and User Guide.  We don't have
tests for UI features in most cases (although there is a suite of
tests to make sure the keyboard works correctly, but this is a real
PITA to exercise because it cannot really be done automatically,
except to some extent on X).  I would think Emacs and most packages
would also lack UI tests.

ERT has some UI tests.  (Maybe just one, I don't remember.)

  >  worth the trouble.  Still, do you think there's a strict boundary
  >  between shared tests and implementation-specific tests, or a continuum?

As I wrote before, in my experience, f?boundp is sufficient in most
cases to check for version- or implementation-specific tests.

The implementation-specific tests are unusual, and mostly happen when
functionality is partially moved from Lisp to C or vice-versa,
resulting in the creation of an -internal version of some function.
Once again, (fboundp 'foo-internal) will usually catch that.

OK, that sounds good.

  >  I was trying to say that it would be easier to write and maintain
  >  tests if the tests for X.el were in X-tests.el in the same
  >  directory

That may be true, but in practice I don't know any large applications
that are organized that way.  Do you?

Yes. Chromium is a fairly large code base that seems to have .cc, .h and _unittest.cc files next to each other, see, e.g., http://src.chromium.org/viewvc/chrome/trunk/src/remoting/base/ . I know about other proprietary examples but didn't look any further for open-source ones.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]