Re: [Orgmode] Re: Testing --- again...

[Eric Schulte]

Hi,

So, I've been using the framework in the combined-testing branch this
morning writing tests to strap down my daily Babel bug fixes, and I'm
really liking ERT.

I wonder, can we commit to the combined-testing branch, and if so could
we fold it into the master branch?  It would make my test driven bug
fixing a much smoother process, and would remove the need to rebase the
combined-testing branch against master and "git push -f" the changes up
to repo.or.cz which just feels wrong.

Thoughts?

-- Eric

Sebastian Rose <address@hidden> writes:

> "Eric Schulte" <address@hidden> writes:
>> Hi,
>>
>> I've taken the liberty of merging our two testing branches into the new
>> "combined-testing" branch.  This now includes both ert and jump.el as
>> git submodules, which can be installed with
>>
>>   git submodule init
>>   git submodule update
>>
>> after checking out the branch.  In merging the two org-test.el files, I
>> was able to remove much of the existing code through using which-func,
>> jump.el.  The new navigation functionality will work regardless of the
>> directory structure, so tests for file
>>
>>   lisp/org-foo.el
>>
>> can be located in either of the following
>>
>>   testing/lisp/test-org-foo.el
>>   testing/lisp/org-foo.el/test.el
>>
>> Additionally the navigation functions defined in jump.el should be
>> easily extensible to accommodate new naming schemas, so ideally every
>> test author for a particular file can use whatever naming system they
>> prefer.  Note that the navigation function `org-test-jump' when called
>> with a prefix argument uses your code from
>> `org-test-edit-buffer-file-tests' to create the test file if it is not
>> already present.
>>
>> I think I retained most of the functionality from your version of
>> org-test.el in the merge but please let me know if I broke something.
>> In my mind this merged version should be small clean and maintainable
>> and hopefully flexible enough to handle whatever needs we identify
>> during the course of writing the tests.  How would you feel about using
>> this as the new base of test development?
>>
>> Best -- Eric
>>
>> also I have some inline comments below
>
>
> Hi Eric,
>
>
> that's good news!
>
>
>> Sebastian Rose <address@hidden> writes:
>>>   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>
>>>   
>>>   ??
>>>
>>
>> I'm not sure that it does include anything new, but it's nice to re-use
>> existing packages.
>
>
> And a dependency.
>
>
>>
>>> * 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
>>>
>>>
>>
>> Wouldn't we want the keys in the elisp-mode key map, since we'll be
>> doing the testing work from elisp?
>
> Errrmmm, yes, we definetively want the keys in the emacs-lisp key map :)
>
>
>>  Although I guess we may want to run
>> tests from within Org-mode files, but then we could do that with a Babel
>> block and dump the results to a table. :)
>
> Ho ho ho ho ho!
>
>
>
>>> * 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"? 
>>>
>>
>> oh, good point, maybe we'd need to use the "eql" or "tag" ert selectors
>> in this case.
>
>
>
> It's a flaw in Org's namespace actually.  A defun's name in org.el could
> clash with the name of a defun in another file in org-mode/lisp/.
> The defun `org-imenu-get-tree' in org.el could clash with a defun with
> that very name in a new file "org-imenu.el".
>
> I guess we'll have to handle org.el in a special way.
>
>
>
>>>   If you checkout ert-testing, eval testing/org-test.el and do
>>>
>>>      M-x org-test-edit-buffer-file-tests
>>>
>>
>> In the combined-testing branch you'd do this by calling org-test-jump
>> with a prefix argument.
>
>
> Perfect.
>
>
>
>>>   Every one who saw that directory structure simply asked "don't you
>>>   think it's overkill?" :D  I'll probably drop that.
>>>
>>
>> heh, yea I'd lean towards getting into the writing of tests and then
>> leaving our implementation flexible enough so that we can adopt this
>> more fine-grained directory structure when/if it becomes necessary.
>
>
> Eric, so just let's skip the directory structure.  We could always
> enforce something like that once we feel it's necessary.
>
> We just want some reliable way to load the sensible tests (for a defun,
> file, module or whatever) and execute them with just a key stroke.
>
> Adding new tests for an existing elisp file should be just as easy.
>
> As jump.el and which-func.el do part of that job reliably it's perfectly
> fine to go that way.
>
>
>
>
>   Sebastian