Re: [PATCH] org-test: Create a collaborative test set for Org buffer parser

[Max Nikulin]

Sorry for delay. I expected that a next step with inline raw AST 
fragments would be easier, but I have got working example for parser 
tests grouped in single file earlier.

Certainly org files may be source for parser tests. They are readable 
enough to be convenient for developers and, I hope, it would not require 
a lot of work to convert them in machine-readable files. However tests 
should be distributed in some format(s) with widely available parsers:
s-expressions, YAML, JSON. I am against JSON for source files since 
working with multiline text will likely be a pain (besides editing of 
files, patches and VCS diffs should be taken into account).

Actually there is a requirement for external projects related to parser 
already. Expected results are provided as S-expressions.

For simplicity I described a test suite with a couple of cases using 
s-expressions (see attachments). Names of macro an functions are 
arbitrary. Interface should be like

    (demo-parse-test-suite "demo-test-suite.el")

Current implementation creates an ert test for each entry in such file, 
but it may be changed later. I just had example of macro for 
parametrized test from earlier experiments.

On 15/12/2021 20:23, Ihor Radchenko wrote:
> Max Nikulin writes:
> > On 11/12/2021 21:39, Ihor Radchenko wrote:
> > > The attached patch is an attempt to create something like shared repo
> > > for Org element parser tests.
> >
> > "[PATCH]" prefix in the subject might be a reason why you message
> > received less attention than it should.

At least Tom and Timothy have their parsers, so I expected some response 
from them. I am unsure whether posts about Organice were from developers 
or from users. Patch is something too internal to development of namely 
Org Mode as Emacs major mode. Once I asked to avoid proposal to 
integrate everything meaning mostly particular person who was extremely 
active that time, but it had effect on more people than I thought. You 
intention may have stronger result than it should as well.

> I am not sure here. In a way, we already have such a format in
> test-org-element.el:
>
> (ert-deftest test-org-element/bold-parser ()
>    "Test `bold' parser."
>    ;; Standard test.
>    (should
>     (org-test-with-temp-text "*bold*"
>       (org-element-map (org-element-parse-buffer) 'bold #'identity nil t))))

It is a bit harder to parse than it is acceptable for external tools. 
However it may be converted to more convenient format using elisp 
facilities.

> So, in addition to writing the Org parser, third-party dev
> will also have to write a parser for the test format.

I assume available parser for some wide spread format and some simple 
interpretation of the structures specific to these tests.

> Most existing parser libraries can
> handle individual files, but not individual pieces of text grouped into
> bigger file using yet another standard convention.

It should take a several line of code to put string input into a 
temporary file. Likely it is possible to implement interface of file 
stream for input string. Finally, it may stimulate developers to add a 
method that parses strings.

I found the following test corpus impressive and unmanageable in the 
form of separate files:
https://github.com/tgbugs/laundry/blob/master/laundry/test.rkt

> But is there a
> standard multi-test in one file format that can be used in multiple
> programming languages?

Some testing frameworks have facilities for parametrized tests with 
lists of arbitrary structures, others explicitly recommends to write a 
loop over such lists.

> Or even allow inline tests via buffer-local after-save-hook:
>
>     - text :: "*Bold* emphasis"
>       - keywords :: emphasis, heading
>       - description :: Despite line is started from a star, there is no
>                        space after it, so it is not a heading.
>
> Upon save, the text:: field will be automatically converted to a
> test-hash.org+test-hash.el files.

Or to a single file with some top-level metadata and a list (maybe 
nested lists) of tests. Unsure that such files should be stored in git.

> > Version of Org and test set should be included into metadata for the
> > whole suite.
>
> If the test set is distributed together with Org, I see no reason to do
> it. Otherwise, the test set should simply track bugfix and main branches
> of Org and follow Org releases. Does it sound reasonable?

I have no particular opinion if test sources should be maintained in the 
same repository with Org or Emacs. If test are described in Org files 
then test suites should be distributed using some other way.

> > Since partial compliance is assumed, format of test results should be
> > declared as well to be able to publish overview or comparison.
>
> I provided a short description of the format in the README (see the
> original patch). Is it not enough?

I mean result of *group* of tests to present comparison of parsers. 
Unsure if JUnit XML files are appropriate.

> > Are properties like :begin and :end mandatory for reference results of
> > parsing? They make structures more verbose and harder to read. Often it
> > is enough to compare content and similar properties.
>
> I afraid that if we put contents of every headline/element in place of
> :begin :end, the results will be even less readable. The results will
> have to dump multiple cumulative instances of the original file.

I had in mind that only leaf elements have contents. It may result in 
some ambiguity however.

> Actually, there have been talks about including Org mode tests into
> Emacs itself (https://yhetil.org/emacs-devel/87o8629h8g.fsf_-_@gmx.de/)

I have seen proposals to drop separate repository for Org and do 
everything inside the one for Emacs earlier. In my opinion, it would 
mean broken compatibility with earlier version of Emacs, so I do not 
like it. On the other hand I am not an active developer, so my arguments 
may be ignored.

P.S.

Output or Ert requires more tuning:

---- >8 ----

Selector: t
Passed:  1
Failed:  1 (1 unexpected)
Skipped: 0
Total:   2/2

Started at:   2021-12-19 14:13:54+0700
Finished.
Finished at:  2021-12-19 14:13:54+0700

F.

F demo-parse-test/demo-test-suite--bold-emphasis-at-beginning-of-line
    Bold text marker at beginning of line should not be confused with 
heading: no space after star (‘demo-parse-test/demo-test-suite’)
    (ert-test-failed
     ((should
       (funcall #<subr equal>
                 '(org-data ... ...)
                 (apply #'demo-test-parse-input '...)))
      :form
      (funcall #<subr equal>
                (org-data
		 (:begin 1 :contents-begin 1 :contents-end 13 :end 13 :post-affiliated 
1 ...)
                 (paragraph
		  (:begin 1 :contents-begin 1 :contents-end 13 :end 13 
:post-affiliated 1 ...)
                  (bold ... "Bold text")))
                (org-data
		 (:begin 1 :contents-begin 1 :contents-end 13 :end 13 :post-affiliated 
1 ...)
                 (section
		  (:begin 1 :contents-begin 1 :contents-end 13 :end 13 
:post-affiliated 1 ...)
                  (paragraph ... ... "
"))))
      :value nil))

demo-test-suite.el
Description: Text Data

demo-test.el
Description: Text Data

demo-test-suite.json
Description: application/json

demo-test-suite.yaml
Description: application/yaml