* Re: org-html link building diff
@ 2010-04-29 22:24 Tom Breton (Tehom)
2010-05-01 12:01 ` Carsten Dominik
2010-05-15 12:29 ` Carsten Dominik
0 siblings, 2 replies; 18+ messages in thread
From: Tom Breton (Tehom) @ 2010-04-29 22:24 UTC (permalink / raw
To: emacs-orgmode
> Hi Tom,
>
> On Apr 28, 2010, at 5:01 AM, Tom Breton (Tehom) wrote:
>
>>
>> The changes are essentially made and pass my tests now, there's mostly
housekeeping now: pull, merge, push.
>>
>>> Yes. Send me your name on repo.or.cz and I'll add push for you.
Please create your own branch and stay on it.
>>
>> It is "Tehom".
>
> I have added you.
Oops, when I went to push, I realized that I had capitalized that but it's
apparently not capitalized on repo.or.cz. It's "tehom".
My branch is called "tehom-master" and the branch that treats link export
based on it is called html-export-refactor-build-link
Tom Breton (Tehom)
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: org-html link building diff
2010-04-29 22:24 org-html link building diff Tom Breton (Tehom)
@ 2010-05-01 12:01 ` Carsten Dominik
2010-05-15 12:29 ` Carsten Dominik
1 sibling, 0 replies; 18+ messages in thread
From: Carsten Dominik @ 2010-05-01 12:01 UTC (permalink / raw
To: Tom Breton (Tehom); +Cc: emacs-orgmode
On Apr 30, 2010, at 12:24 AM, Tom Breton (Tehom) wrote:
>> Hi Tom,
>>
>> On Apr 28, 2010, at 5:01 AM, Tom Breton (Tehom) wrote:
>>
>>>
>>> The changes are essentially made and pass my tests now, there's
>>> mostly
> housekeeping now: pull, merge, push.
>>>
>>>> Yes. Send me your name on repo.or.cz and I'll add push for you.
> Please create your own branch and stay on it.
>>>
>>> It is "Tehom".
>>
>> I have added you.
>
> Oops, when I went to push, I realized that I had capitalized that
> but it's
> apparently not capitalized on repo.or.cz. It's "tehom".
OK, I changed that.
>
> My branch is called "tehom-master" and the branch that treats link
> export
> based on it is called html-export-refactor-build-link
Will check it out later next week. Thanks!
- Carsten
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: org-html link building diff
2010-04-29 22:24 org-html link building diff Tom Breton (Tehom)
2010-05-01 12:01 ` Carsten Dominik
@ 2010-05-15 12:29 ` Carsten Dominik
2010-05-15 21:37 ` Tom Breton (Tehom)
1 sibling, 1 reply; 18+ messages in thread
From: Carsten Dominik @ 2010-05-15 12:29 UTC (permalink / raw
To: Tom Breton (Tehom); +Cc: emacs-orgmode
Hi Tom,
what is the status of this development? Ready for prime time? If
yes, can you please rebase to master and send me the pointer to the
branch again?
Or is there still stuff unclear? Can I help?
Thanks!
- Carsten
On Apr 30, 2010, at 12:24 AM, Tom Breton (Tehom) wrote:
>> Hi Tom,
>>
>> On Apr 28, 2010, at 5:01 AM, Tom Breton (Tehom) wrote:
>>
>>>
>>> The changes are essentially made and pass my tests now, there's
>>> mostly
> housekeeping now: pull, merge, push.
>>>
>>>> Yes. Send me your name on repo.or.cz and I'll add push for you.
> Please create your own branch and stay on it.
>>>
>>> It is "Tehom".
>>
>> I have added you.
>
> Oops, when I went to push, I realized that I had capitalized that
> but it's
> apparently not capitalized on repo.or.cz. It's "tehom".
>
> My branch is called "tehom-master" and the branch that treats link
> export
> based on it is called html-export-refactor-build-link
>
> 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
- Carsten
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: org-html link building diff
2010-05-15 12:29 ` Carsten Dominik
@ 2010-05-15 21:37 ` Tom Breton (Tehom)
2010-05-16 5:03 ` Carsten Dominik
2010-05-16 5:20 ` Carsten Dominik
0 siblings, 2 replies; 18+ messages in thread
From: Tom Breton (Tehom) @ 2010-05-15 21:37 UTC (permalink / raw
To: Carsten Dominik; +Cc: emacs-orgmode
> Hi Tom,
>
> what is the status of this development? Ready for prime time? If
> yes, can you please rebase to master and send me the pointer to the
> branch again?
I believe it is ready, though I haven't heard any feedback. I pushed the
changes on about the 4th of may.
> Or is there still stuff unclear? Can I help?
Maybe. I hadn't done this before, so some feedback and (if needed)
correction would be appreciated.
I had to change the url to git+ssh so it would authenticate me, but when I
pushed, it was visible in the public (non-ssh) git repo, so I thought it
was visible to everybody. Isn't it?
I thought I had done what you wanted by creating a branch for all my
changes ever (tehom-master) and rebasing the org-html link changes on that
(html-export-refactor-build-link). Is that working for you? If not, how
can I fix it?
Tom Breton (Tehom)
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: org-html link building diff
2010-05-15 21:37 ` Tom Breton (Tehom)
@ 2010-05-16 5:03 ` Carsten Dominik
2010-05-18 0:59 ` Tom Breton (Tehom)
2010-05-16 5:20 ` Carsten Dominik
1 sibling, 1 reply; 18+ messages in thread
From: Carsten Dominik @ 2010-05-16 5:03 UTC (permalink / raw
To: Tom Breton (Tehom); +Cc: emacs-orgmode
Hi Tom,
I have now taken a brief look at the html-export-refactor-build-link
patch. I see that in addition to changing org-html, it create a new
file, with tests. While it is great that you have defined tests, this
meant that I cannot simply apply he patch to the master without making
unwanted changes.
If we build a test strucure, it should be in a completely separate
directory, not in, for example, the lisp directory.
Could you please make me a branch which contains only the changes that
would go into org?
And if you want to provide a test framework for Org, pleas, by all
means, go ahead, build it and document it so that we can all use it.
Maybe we could make a "tests" subdirectory in the git repo that would
contain it...
Thanks
- Carsten
On May 15, 2010, at 11:37 PM, Tom Breton (Tehom) wrote:
>> Hi Tom,
>>
>> what is the status of this development? Ready for prime time? If
>> yes, can you please rebase to master and send me the pointer to the
>> branch again?
>
> I believe it is ready, though I haven't heard any feedback. I
> pushed the
> changes on about the 4th of may.
>
>> Or is there still stuff unclear? Can I help?
>
> Maybe. I hadn't done this before, so some feedback and (if needed)
> correction would be appreciated.
>
> I had to change the url to git+ssh so it would authenticate me, but
> when I
> pushed, it was visible in the public (non-ssh) git repo, so I
> thought it
> was visible to everybody. Isn't it?
>
> I thought I had done what you wanted by creating a branch for all my
> changes ever (tehom-master) and rebasing the org-html link changes
> on that
> (html-export-refactor-build-link). Is that working for you? If
> not, how
> can I fix it?
>
> Tom Breton (Tehom)
>
>
- Carsten
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: org-html link building diff
2010-05-15 21:37 ` Tom Breton (Tehom)
2010-05-16 5:03 ` Carsten Dominik
@ 2010-05-16 5:20 ` Carsten Dominik
2010-05-18 1:01 ` Test-file naming conventions - mine and suggested for org Tom Breton (Tehom)
1 sibling, 1 reply; 18+ messages in thread
From: Carsten Dominik @ 2010-05-16 5:20 UTC (permalink / raw
To: Tom Breton (Tehom); +Cc: emacs-orgmode
On May 15, 2010, at 11:37 PM, Tom Breton (Tehom) wrote:
>> Hi Tom,
>>
>> what is the status of this development? Ready for prime time? If
>> yes, can you please rebase to master and send me the pointer to the
>> branch again?
>
> I believe it is ready, though I haven't heard any feedback. I
> pushed the
> changes on about the 4th of may.
>
>> Or is there still stuff unclear? Can I help?
>
> Maybe. I hadn't done this before, so some feedback and (if needed)
> correction would be appreciated.
>
> I had to change the url to git+ssh so it would authenticate me, but
> when I
> pushed, it was visible in the public (non-ssh) git repo, so I
> thought it
> was visible to everybody. Isn't it?
Yes. It is the same repo - ssh access allows you to push, that is all.
>
> I thought I had done what you wanted by creating a branch for all my
> changes ever (tehom-master) and rebasing the org-html link changes
> on that
> (html-export-refactor-build-link). Is that working for you? If
> not, how
> can I fix it?
I think the best would be to have individual topic branches that you
devellpp for yourself, on your machine at home, and that you only push
them to the repo when you want others or me to look at them.
- Carsten
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: org-html link building diff
2010-05-16 5:03 ` Carsten Dominik
@ 2010-05-18 0:59 ` Tom Breton (Tehom)
2010-05-18 4:47 ` Carsten Dominik
0 siblings, 1 reply; 18+ messages in thread
From: Tom Breton (Tehom) @ 2010-05-18 0:59 UTC (permalink / raw
To: Carsten Dominik; +Cc: emacs-orgmode
Hi, Carsten. The new changes are pushed as
tehom-html-export-refactor-build-link
I couldn't undo the basing onto tehom-master, try though I might.
Something to do with intermediate changes that I couldn't fast-forward
and that I probably edited wrong. So I made a separate branch,
tehom-html-export-refactor-build-link, which is now pushed to the
repo. So tehom-master and html-export-refactor-build-link are already
obsolete.
I moved the tests into top-level directory testing, as you asked. I'm
going to write a separate post describing the test conventions I use.
Now a question: IIUC you want a branch that has no tests, that
"contains only the changes that would go into org". Since I develop
tests and code at about the same time (tests slightly before code),
I'm not sure how to arrange the branching in a maintainable way.
I could of course make a one-time branch that just removes the testing
directory. But then what happens for any future fixes? Seems like
each time I'd have to rebase that branch and pick thru changes and
make it discard each change that deals with testing/. It seems hard
to maintain.
Tom Breton (Tehom)
^ permalink raw reply [flat|nested] 18+ messages in thread
* Test-file naming conventions - mine and suggested for org
2010-05-16 5:20 ` Carsten Dominik
@ 2010-05-18 1:01 ` Tom Breton (Tehom)
2010-05-21 11:27 ` Carsten Dominik
0 siblings, 1 reply; 18+ messages in thread
From: Tom Breton (Tehom) @ 2010-05-18 1:01 UTC (permalink / raw
To: Carsten Dominik; +Cc: emacs-orgmode
In developing emtest, I've given some thought to conventions for test
files. My convention is that:
* tests of foo.el go into foo/tests.el
* With feature name foo/tests
* Any shared testhelp goes into foo/testhelp.el
* With feature name foo/testhelp
* Example files go in foo/examples/
* Alternative, they can all be placed in another directory
hierarchy, like "org/testing/foo/tests.el" as long as
"org/testing" is in the load-path (emacs doesn't know the
difference).
I welcome any comments on this convention. I considered it carefully;
I wrote a small document considering the alternatives and chose this
as best. But it's young enough that it could be changed, were strong
arguments made towards some alternative.
Tom Breton (Tehom)
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: org-html link building diff
2010-05-18 0:59 ` Tom Breton (Tehom)
@ 2010-05-18 4:47 ` Carsten Dominik
2010-05-18 12:26 ` Sebastian Rose
0 siblings, 1 reply; 18+ messages in thread
From: Carsten Dominik @ 2010-05-18 4:47 UTC (permalink / raw
To: Tom Breton (Tehom); +Cc: emacs-orgmode
On May 18, 2010, at 2:59 AM, Tom Breton (Tehom) wrote:
>
> Hi, Carsten. The new changes are pushed as
> tehom-html-export-refactor-build-link
>
> I couldn't undo the basing onto tehom-master, try though I might.
> Something to do with intermediate changes that I couldn't fast-forward
> and that I probably edited wrong. So I made a separate branch,
> tehom-html-export-refactor-build-link, which is now pushed to the
> repo. So tehom-master and html-export-refactor-build-link are already
> obsolete.
>
> I moved the tests into top-level directory testing, as you asked. I'm
> going to write a separate post describing the test conventions I use.
>
> Now a question: IIUC you want a branch that has no tests, that
> "contains only the changes that would go into org". Since I develop
> tests and code at about the same time (tests slightly before code),
> I'm not sure how to arrange the branching in a maintainable way.
Hi Tom,
If we decide to use your emtests framework for Org on a brader basis,
then there would be no reason to have a branch free of tests. This is
only necessary because I am supposed to apply your patches, but
without the testing framework at the moment.
Maybe we should just go ahead and start using emtest for Org-mode.
Why don't you go ahead and propose this in a mail to emacs-orgmode.
Lets see if there is any resistance by people who understand more
about testing than I do. If not, we go ahead and do it.
I would still prefer to have the tests in a separate directory if your
package allows to do so. Hope that this is no problem?
I guess all the emtest code itself would then have to go into the org-
mode git repo as well, so that we can use it?
And we should develop a make target that will run all tests.
- Carsten
>
> I could of course make a one-time branch that just removes the testing
> directory. But then what happens for any future fixes? Seems like
> each time I'd have to rebase that branch and pick thru changes and
> make it discard each change that deals with testing/. It seems hard
> to maintain.
>
> Tom Breton (Tehom)
>
>
- Carsten
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: org-html link building diff
2010-05-18 4:47 ` Carsten Dominik
@ 2010-05-18 12:26 ` Sebastian Rose
0 siblings, 0 replies; 18+ messages in thread
From: Sebastian Rose @ 2010-05-18 12:26 UTC (permalink / raw
To: Carsten Dominik; +Cc: emacs-orgmode, Tom Breton (Tehom)
Carsten Dominik <carsten.dominik@gmail.com> writes:
> On May 18, 2010, at 2:59 AM, Tom Breton (Tehom) wrote:
>
>>
>> Hi, Carsten. The new changes are pushed as
>> tehom-html-export-refactor-build-link
>>
>> I couldn't undo the basing onto tehom-master, try though I might.
>> Something to do with intermediate changes that I couldn't fast-forward
>> and that I probably edited wrong. So I made a separate branch,
>> tehom-html-export-refactor-build-link, which is now pushed to the
>> repo. So tehom-master and html-export-refactor-build-link are already
>> obsolete.
>>
>> I moved the tests into top-level directory testing, as you asked. I'm
>> going to write a separate post describing the test conventions I use.
>>
>> Now a question: IIUC you want a branch that has no tests, that
>> "contains only the changes that would go into org". Since I develop
>> tests and code at about the same time (tests slightly before code),
>> I'm not sure how to arrange the branching in a maintainable way.
>
> Hi Tom,
>
> If we decide to use your emtests framework for Org on a brader basis, then there
> would be no reason to have a branch free of tests. This is only necessary
> because I am supposed to apply your patches, but without the testing framework
> at the moment.
>
> Maybe we should just go ahead and start using emtest for Org-mode. Why don't
> you go ahead and propose this in a mail to emacs-orgmode. Lets see if there is
> any resistance by people who understand more about testing than I do. If not,
> we go ahead and do it.
We had that discussion here aleady, and the result is: we have no test
framework to work with.
Better just do it ;)
Sebastian
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Test-file naming conventions - mine and suggested for org
2010-05-18 1:01 ` Test-file naming conventions - mine and suggested for org Tom Breton (Tehom)
@ 2010-05-21 11:27 ` Carsten Dominik
2010-05-24 21:26 ` Proposal: Emtest as tester Tom Breton (Tehom)
0 siblings, 1 reply; 18+ messages in thread
From: Carsten Dominik @ 2010-05-21 11:27 UTC (permalink / raw
To: Tom Breton (Tehom); +Cc: emacs-orgmode
Hi Tom,
as you may or may not have noticed, by merging your patch I actually
have created the new directory "testing" in the org-mode git repository.
Can I invite you to build this out into a testing system for Org-mode?
Basically, I think, this would mean adding your testing package (is it
called emt?)
and documenting for other how to create and run tests like the ones
which you have in
testing/org-html/tests.el
Cheers
- Carsten
On May 18, 2010, at 3:01 AM, Tom Breton (Tehom) wrote:
> In developing emtest, I've given some thought to conventions for test
> files. My convention is that:
>
> * tests of foo.el go into foo/tests.el
>
> * With feature name foo/tests
>
> * Any shared testhelp goes into foo/testhelp.el
>
> * With feature name foo/testhelp
>
> * Example files go in foo/examples/
>
> * Alternative, they can all be placed in another directory
> hierarchy, like "org/testing/foo/tests.el" as long as
> "org/testing" is in the load-path (emacs doesn't know the
> difference).
>
> I welcome any comments on this convention. I considered it carefully;
> I wrote a small document considering the alternatives and chose this
> as best. But it's young enough that it could be changed, were strong
> arguments made towards some alternative.
>
> Tom Breton (Tehom)
>
>
- Carsten
^ permalink raw reply [flat|nested] 18+ messages in thread
* Proposal: Emtest as tester
2010-05-21 11:27 ` Carsten Dominik
@ 2010-05-24 21:26 ` Tom Breton (Tehom)
2010-05-24 22:56 ` Dan Davison
` (2 more replies)
0 siblings, 3 replies; 18+ messages in thread
From: Tom Breton (Tehom) @ 2010-05-24 21:26 UTC (permalink / raw
To: Carsten Dominik; +Cc: emacs-orgmode
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.
* 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)
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Proposal: Emtest as tester
2010-05-24 21:26 ` Proposal: Emtest as tester Tom Breton (Tehom)
@ 2010-05-24 22:56 ` Dan Davison
2010-05-27 20:02 ` Tom Breton (Tehom)
2010-05-25 6:48 ` Carsten Dominik
2010-05-25 8:43 ` Martin Pohlack
2 siblings, 1 reply; 18+ messages in thread
From: Dan Davison @ 2010-05-24 22:56 UTC (permalink / raw
To: Tom Breton (Tehom); +Cc: emacs-orgmode, Carsten Dominik
"Tom Breton (Tehom)" <tehom@panix.com> 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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Proposal: Emtest as tester
2010-05-24 21:26 ` Proposal: Emtest as tester Tom Breton (Tehom)
2010-05-24 22:56 ` Dan Davison
@ 2010-05-25 6:48 ` Carsten Dominik
2010-05-25 8:43 ` Martin Pohlack
2 siblings, 0 replies; 18+ messages in thread
From: Carsten Dominik @ 2010-05-25 6:48 UTC (permalink / raw
To: Tom Breton (Tehom); +Cc: emacs-orgmode
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Proposal: Emtest as tester
2010-05-24 21:26 ` Proposal: Emtest as tester Tom Breton (Tehom)
2010-05-24 22:56 ` Dan Davison
2010-05-25 6:48 ` Carsten Dominik
@ 2010-05-25 8:43 ` Martin Pohlack
2010-05-27 20:13 ` Tom Breton (Tehom)
2 siblings, 1 reply; 18+ messages in thread
From: Martin Pohlack @ 2010-05-25 8:43 UTC (permalink / raw
To: Tom Breton (Tehom); +Cc: emacs-orgmode
Hi Tom,
On 24.05.2010 23:26, 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
>
[...]
I made an attempt earlier to propose a testing framework and wrote some
thoughts in an email thread:
http://www.mail-archive.com/emacs-orgmode@gnu.org/msg22558.html
Would your proposal cover my example-based approach? How hard would it
be to turn a typical bug report into a test case?
Cheers,
Martin
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Proposal: Emtest as tester
2010-05-24 22:56 ` Dan Davison
@ 2010-05-27 20:02 ` Tom Breton (Tehom)
0 siblings, 0 replies; 18+ messages in thread
From: Tom Breton (Tehom) @ 2010-05-27 20:02 UTC (permalink / raw
To: Dan Davison; +Cc: emacs-orgmode, Carsten Dominik
> "Tom Breton (Tehom)" <tehom@panix.com> 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?
At the moment it lives in a tarball. I will put up an updated version at
panix.com/~tehom/my-code/emtest-bundle.tar.gz That's emtest plus all
supporting packages. (Should be all, I may have missed some dependencies
I have locally)
I'm looking to have it hosted on Savannah. You've given me the impetus to
go and do that, so thanks.
> Is there an Org repo out there demonstrating how it would
> integrate,
Right now the only git repo lives on my machine.
> and/or some documentation and examples of usage?
Right now the documentation consists of my design notes, which are
probably confusing since they include as-built, unrealized plans,
self-debates over the right approach, discarded and/or obsolete plans,
bugfixes, and progress notes. I will try to write up something more
accessible.
Every feature has examples of usage in the tests.el files, one of the
virtues of tests.
Tom Breton (Tehom)
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Proposal: Emtest as tester
2010-05-25 8:43 ` Martin Pohlack
@ 2010-05-27 20:13 ` Tom Breton (Tehom)
2010-06-07 16:11 ` Benjamin Andresen
0 siblings, 1 reply; 18+ messages in thread
From: Tom Breton (Tehom) @ 2010-05-27 20:13 UTC (permalink / raw
To: Martin Pohlack; +Cc: emacs-orgmode, Tom Breton
> Hi Tom,
>
>>
> [...]
>
> I made an attempt earlier to propose a testing framework and wrote some
> thoughts in an email thread:
>
> http://www.mail-archive.com/emacs-orgmode@gnu.org/msg22558.html
I read that. Interesting.
> Would your proposal cover my example-based approach? How hard would it
> be to turn a typical bug report into a test case?
Not hard at all. Most of what you propose is already supported. You
would put both the input and expected output in FOO/examples/UNIQUE-NAMES
The sequence of commands can easily be made into a test case.
`emt:insert' inserts the template for you (choose `emt:insert-test'), then
paste it in.
Rather than saving the buffer, you probably want to do it all inside a
mock buffer, like (excuse the online-editor formatting)
(emtb:with-buf (:file INPUT-FILE-NAME)
(operations)
(emtb:buf-contents-matches (:file OUTPUT-FILE-NAME))
For testing only visible output, you'd presumably use org-export-visible
and compare that buffer's contents to what's expected.
Wildcard comparisons in files are not yet supported. I will take that as
a feature request.
Tom Breton (Tehom)
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Proposal: Emtest as tester
2010-05-27 20:13 ` Tom Breton (Tehom)
@ 2010-06-07 16:11 ` Benjamin Andresen
0 siblings, 0 replies; 18+ messages in thread
From: Benjamin Andresen @ 2010-06-07 16:11 UTC (permalink / raw
To: emacs-orgmode
Hey Tom,
I was wondering what the status was of the emtest inclusion in org-mode?
Looks like the tehom-master in the org-mode repo is not the right one
(last commit Wed Apr 28 16:39:59 2010 -0500)
br,
benny
^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2010-06-07 16:11 UTC | newest]
Thread overview: 18+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-04-29 22:24 org-html link building diff Tom Breton (Tehom)
2010-05-01 12:01 ` Carsten Dominik
2010-05-15 12:29 ` Carsten Dominik
2010-05-15 21:37 ` Tom Breton (Tehom)
2010-05-16 5:03 ` Carsten Dominik
2010-05-18 0:59 ` Tom Breton (Tehom)
2010-05-18 4:47 ` Carsten Dominik
2010-05-18 12:26 ` Sebastian Rose
2010-05-16 5:20 ` Carsten Dominik
2010-05-18 1:01 ` Test-file naming conventions - mine and suggested for org Tom Breton (Tehom)
2010-05-21 11:27 ` Carsten Dominik
2010-05-24 21:26 ` Proposal: Emtest as tester Tom Breton (Tehom)
2010-05-24 22:56 ` Dan Davison
2010-05-27 20:02 ` Tom Breton (Tehom)
2010-05-25 6:48 ` Carsten Dominik
2010-05-25 8:43 ` Martin Pohlack
2010-05-27 20:13 ` Tom Breton (Tehom)
2010-06-07 16:11 ` Benjamin Andresen
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.