Thanks for the feedback. There's no special reason for the external test data file or repeated executable-find calls. I was following the convention from ob-C. I'll make those changes.
ob-haxe and ob-java both involve a few changes to ob-core to allow temp directories instead of just temp files. Should I submit that as a separate patch? On Sun, Sep 6, 2020 at 11:24 AM Kyle Meyer <k...@kyleam.com> wrote: > Hi ian, > > It looks like this library is instead going to be available through an > ELPA, but FWIW here are a couple of comments on the tests. > > ian martins writes: > > > diff --git a/testing/examples/ob-haxe-test.org b/testing/examples/ > ob-haxe-test.org > > new file mode 100644 > > index 000000000..ba9119d58 > > --- /dev/null > > +++ b/testing/examples/ob-haxe-test.org > > @@ -0,0 +1,247 @@ > > +#+Title: a collection of examples for ob-haxe tests > > +#+OPTIONS: ^:nil > > +* Simple > > + :PROPERTIES: > > + :ID: 966875e9-d10e-406c-9211-449555e3d3b2 > > + :END: > > +#+name: simple > > +#+begin_src haxe :results output silent > > + Sys.print(42); > > +#+end_src > > I know some other babel tests use a separate .org file, but I find this > setup harder to follow compared to having the Org content within the > test (e.g. using org-test-with-temp-text or > org-test-with-temp-text-in-file). Perhaps I'm missing why it's needed > in this case though. > > > diff --git a/testing/lisp/test-ob-haxe.el b/testing/lisp/test-ob-haxe.el > [...] > > +;;; Code: > > +(org-test-for-executable "haxe") > > +(unless (featurep 'ob-haxe) > > + (signal 'missing-test-dependency "Support for haxe code blocks")) > > + > > +(ert-deftest ob-haxe/simple () > > + "Hello world program." > > + (if (executable-find org-babel-haxe-command) > > I think you can avoid the executable-find here and in all the other > tests because you have (org-test-for-executable "haxe") at the beginning > of the file. >
