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 <kyle@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.