Unit Testing with OpenFL

#1

I’m sure this topic comes up a lot, but it’s surprisingly difficult to find information about it. I’m starting up a new flixel project and want to have good unit testing from the start, but am having difficulty finding a “nice” way to do it.

After fiddling for a bit, I did come up with a way to unit test by executing lime test text.xml neko, effectively invoking lime on a test project which includes the sources for both my project and test files. It works, but it takes a while (~7 seconds) to build and has to bring up a window in the process. And it takes that long even if I just want to run a single test.

At first I was trying to use standard haxe compilation by specifying lime, openfl, and flixel as libraries, but it was popping up with a plethora of errors, such as openfl.display.BitmapData should be flash.display.BitmapData.

So I’m mostly curious about this: Has the community landed on a canonical way of doing unit testing in an OpenFL project, or is what I’m currently doing standard practice?

#2

We currently use four different methods of unit testing in OpenFL:

  1. Our functional tests in OpenFL are a standard OpenFL project: https://github.com/openfl/openfl/tree/master/test/haxelib/functional

    I have some code to help us advance between multiple tests which must be confirmed manually.

  2. Our unit tests for OpenFL do not use the Lime command-line tools, and actually do not use Lime at all. They use the munit runner, but from an OpenFL fork (https://github.com/openfl/munit) that has fixes.

    These tests are currently not cross-platform, and are meant to be logic-only. It’s currently designed to use Neko only. We’re working on getting more (and better) tests that are truly isolated to individual units of classes

  3. Integration testing is re-using the same unit test classes we have above, but are run independently for multiple different platforms. We use the same munit runner for web (Flash/HTML5) testing, but also run standard Lime-based projects for other platforms, and the output is written to the command-line. AIR, Neko and C++ work that way.

  4. For NPM, we have testing using Webpack and Mocha.js (with Mocha-Chrome) for headless browser testing. This uses the NPM release of OpenFL

Integration Tests