emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Sebastian Rose <sebastian_rose@gmx.de>
To: Eric Schulte <schulte.eric@gmail.com>
Cc: Emacs-orgmode mailing list <emacs-orgmode@gnu.org>,
	Carsten Dominik <carsten.dominik@gmail.com>
Subject: Re: Re: Testing --- again...
Date: Sun, 03 Oct 2010 02:46:43 +0200	[thread overview]
Message-ID: <87ocbbvuig.fsf@gmx.de> (raw)
In-Reply-To: 87sk0ofef3.fsf@gmail.com

"Eric Schulte" <schulte.eric@gmail.com> writes:
> "Eric Schulte" <schulte.eric@gmail.com> writes:
> To illustrate my suggestions, I've thrown together a couple simple Babel
> tests roughly following this outline, currently up in the
> `schulte-testing' branch of the Org-mode repo.
>
> To try it out
> 1) load the testing/org-test.el file
> 2) run `org-load-tests' to load up the entire org-mode test suite
> 3) run `ert' to run the test suite.
> 4) or jump to the definition of `org-babel-get-src-block-info' and run
>    `org-test-current-function' to just run the tests for that function
>
> Best -- Eric

Yes.  I know how running tests looks like:  It looks good :)

Hahaa, I like that code.  It looks so simple :)


To load all files below testing/  is a good suggestion probably.  The
unloading and loading as I implemented it is simply superfluous, if we
suggest that testers no how to eval a buffer or defun (and if they can
change it, they can eval it).



* Question:

  (defun org-test-current-function ()
    "Test the current function."
    (interactive)
    (ert (car (which-function))))
  
  `org-test-test-current-defun' in the ert-testing branch does that, too.
  (But with that superfluous loading/unloading stuff though :-/) But it
  encloses each test inside save-excursion and Co.
  
  What does which-func.el that this function does not:
  
  <#part type="application/emacs-lisp" disposition=inline>
  (defun org-test-which-func ()
    "Return the name of the current defun."
    (save-excursion
      (save-match-data
        (end-of-line)
        (beginning-of-defun)
        (if (looking-at "(defun[[:space:]]+\\([^([:space:]]*\\)[[:space:]]*(")
          (match-string-no-properties 1)
      (error "No defun found around point.")))))
  <#/part>
  
  ??



* Keymap

  We should add keys to the org-mode-map.
  
   C-c t
  
  is still free here.  Or is it in you use it for babel somehow?
  
   C-c t f     org-test-test-current-function
   C-c t b     org-test-test-current-buffer-file




* ERT Selectors

  I see a little namespace problem coming up.  Imagine testing org.el.
  Which ert selector would we use?
  
  "^org" ???  :-/

  Should we create hashes of filenames as selectors (just kidding)?
  Or use the entire filename "^org.el"?  The relative path
  "^lisp/org.el"? 






* About the directory structure:

  It does not burden the user, as tests are loaded and executed
  automatically (per function, per file or all, depending on the command
  used).  But imagine the entire thing grows and someone would add tests
  for all the stuff in emacs/lisp/.  Or add tests files for single
  functions simply because there is so much to test that one file would
  be hard to handle.
  This could cause a lot of clutter.

  Is this too hypothetical?  Hmmm - it might be...

  If you checkout ert-testing, eval testing/org-test.el and do

     M-x org-test-edit-buffer-file-tests

  you're in your test file in the correct directory (which is created if
  it doesn't exist).

     M-x org-test-edit-current-defuns-tests

  creates a file named after the defun you're in.  You'll need to be in
  an elisp file of course.  The testing/ directory will resemble the
  directory structure of the project.

  Every one who saw that directory structure simply asked "don't you
  think it's overkill?" :D  I'll probably drop that.

  

  We could go on on two rails for a while.  I'll need this week to dig
  deeper into ERT and come to conclusions.

  It would be a good thing if we could agree about the keys and the
  selectors (again: "^org"), so that it's painless to switch branches ;)






  Sebastian

  reply	other threads:[~2010-10-03 21:25 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-02  3:51 Testing --- again Sebastian Rose
2010-10-02  8:09 ` Carsten Dominik
2010-10-02 14:53   ` Sebastian Rose
2010-10-02 15:01   ` Sebastian Rose
2010-10-02 17:05     ` Carsten Dominik
2010-10-02 18:12   ` Eric Schulte
2010-10-02 19:33     ` Sebastian Rose
2010-10-02 20:30       ` Eric Schulte
2010-10-02 21:55         ` Eric Schulte
2010-10-03  0:46           ` Sebastian Rose [this message]
2010-10-04  1:26             ` Eric Schulte
2010-10-04  3:59               ` Sebastian Rose
2010-10-04 15:26                 ` Eric Schulte
2010-10-05  0:21                   ` Sebastian Rose
2010-10-05 18:57                     ` Eric Schulte
2010-10-06  0:48                   ` Bernt Hansen
2010-10-06  2:57                     ` Eric Schulte
2010-10-02 22:14         ` Sebastian Rose

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87ocbbvuig.fsf@gmx.de \
    --to=sebastian_rose@gmx.de \
    --cc=carsten.dominik@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=schulte.eric@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).