We have a number of test suites, which are placed in their own folders in this directory.
"RunCi.hx" is the script used by our CIs to run all the test suites. It is possible to configure CIs for your own fork of Haxe on Github using the instructions as follows.
TravisCI provides Linux and Mac builds. However, for forks, it only provides Linux builds unless requested manually.
To set up TravisCI:
- Head to TravisCI, go to the profile page.
- Turn on the switch of your fork. If you couldn't find the repo, try the Sync button on the top to refresh the list.
- If you want to enable browser testing for the JS target, follow the instructions in the SauceLabs section. If not, go to the next step.
- Push to the repo to trigger a new build. The build result should be available at
https://travis-ci.org/<user_name>/haxe
.
AppVeyor provides Windows builds.
To set up AppVeyor:
- Head to AppVeyor, add a new project.
- Select the forked repo under your account.
- Push to the repo to trigger a new build. The build result should be available at
https://ci.appveyor.com/project/<user_name>/haxe
.
SauceLabs provides browser testings. We use TravisCI to drive the test, so you should have TravisCI configured.
To set up SauceLabs:
- Head to the project page of your fork at
https://travis-ci.org/<user_name>/haxe
- Select Settings -> Settings.
- Select the Environment Variables tab.
- Select Add a new variable for the following pairs, keeping the switch off for Display value in build logs.
- name:
SAUCE_USERNAME
, value: your SauceLabs account name - name:
SAUCE_ACCESS_KEY
, value: your SauceLabs access key, which can be found at https://saucelabs.com/account
- name:
- Push to the repo to trigger a new TravisCI build. SauceLabs test results should be available in the JS build log.
It is possible to run it in local machines too:
- Change to this directory.
- Compile the script:
haxe RunCi.hxml
. - Define the test target by
export TEST=$TARGET
(orset "TEST=$TARGET"
on Windows), where$TARGET
should be a comma-seperated list of targets, e.g.neko,macro
. Possible targets aremacro
,neko
,js
,lua
,php
,cpp
,flash9
,java
,cs
,python
, andthird-party
. However,flash9
andthird-party
are not likely to work on local machines (TODO). - Run it:
neko RunCi.n
.
Note that the script will try to look for test dependencies and install them if they are not found. Look at the getXXXDependencies
functions for the details.
The "unit" folder contains a set of unit tests for the Haxe std library. Unit tests can be run separately instead of using "RunCi.hx", which runs all test suites.
Assuming all test dependencies has been installed, we compile and run the unit tests for all targets at once as follows:
- Change to the "unit" directory.
- Compile:
haxe compile.hxml
. - Start a dev server:
nekotools server
. - Open http://localhost:2000/unit.html in your browser.
Cpp unit tests are compiled with -D HXCPP_NO_DEBUG_LINK
(removes debug symbols) to speed up compilation times. You can remove this from compile-cpp.hxml
to be able to open the generated Test-debug.exe
in Visual Studio and debug it. This is useful if it's difficult to figure out why a test is failing, or also which test is failing (for instance with a segmentation fault).
The "sys" folder contains tests for the system targets. It can also be run separately instead of using "RunCi.hx".
Assuming all test dependencies has been installed, we compile and run the sys tests for all targets at once as follows:
- Change to the "sys" directory.
- If you're on Windows, comment out the relevant lines in "run.hxml".
haxe run.hxml
.