* [2025-01-07 19:38] Ihor Radchenko:> Phil Estival <p...@7d.nz> writes:
[...]
Some macros [for test suite] should probably be moved upward
in a file where generic functions which purposes are to help
writing the tests of babel source blocks should be declared.
I do not mind.
But please show which _other_ tests can benefit from the simplification.
This may appear as an unnecessary effort to refactor, or worse,
normalize a code that can benefit from some diversity
yet,
the forms
(should
(equal "<str result>"
(org-test-with-temp-text "<block>"
(org-babel-next-src-block)
(org-trim (org-babel-execute-src-block))))))
or
(org-test-with-temp-text "<block>"
(org-babel-next-src-block)
(should (equal '(<something>) ;; or (should (string= "<str>
(org-babel-execute-src-block))))
;; or org-babel-execute-maybe for ruby and elisp
exist in
test-ob-[maxima,R,sqlite,sed,shell,plantuml,lua,java,julia,lob,octave,perl,python,emacs-lisp].el
Considering it at the repetitive pattern, I think a macro can shorten
those forms to :
(ob-test "<preamble + block>"
:expect "<expected-result>")
and a variant to test or exclude matching regexp
(ob-test "<preamble+block>"
:expect-to-match "<expected regexp to match>")
(ob-test "<preamble+block>"
:expect-to-not-match "<expected-regexp to not match>")
IMHO, they would be easier to read with one additional line feed
(ob-test "
#+begin_src ...
#+end_src"
:expect "<expected-result>")
rather than
(ob-test "#+begin_src ...
#+end_src"
:expect "<expected-result>")
Similar macro/function exists in
ob-emacs-lisp/dynamic-lexical-execute
or ob-sql/command-should-contain.
my 2ยข,
Phil
