Files
wren/test
Will Speak 04a7c9b5c8 Improve Travis Build & Test Coverage
Build Wren for more targets, and run the test suite on both 32 and 64
bit builds.

 * Update the build config to test both with and without NAN_TAGGING
   defined.

 * Updatest `util/test.py` to take the executable suffix as a
   parameter. This allows the makefile to control which binaries will be
   tested.

   Adds a new target to the makefile to be run by travis, this runs the
   test suite against all of the configurations it builds.

 * Gcc on some 32 bit platforms was complaining about numeric overflows
   when -INFINITY was used. Update the logic for converting a double to
   a string to not explicitly check against the literal values.

 * Make CI builds run the tests on both 64 _and_ 32 bit builds.

 * If I limit the number of CPUs on my MBP I can get some of the tests
   to time out, I'm imagining that the specs of the Travis Macs means
   that the same is happening there too. Updated the test script to
   allow an extra few seconds for the test to complete successfully
   before killing it.

 * Due to slight differences in accuracy in some computations tests were
   failing on 32 bit builds. Stop comparing things quite as exactly in
   the cases where it is causing issues.

   For some reason 12.34 was refusing to compare equal to itself. Bad
   show 12.34 :-/. I've also updated the test so it doesn't leak handles
   even if the assertions fail.

 * Double-cast from `double` to `uint32_t` to prevent undefined
   behaviour on overflow of basic integers. This should hopefully
   prevent 32 bit test failures on Linux.

 * Move to a version of LibUV with a fix for the 32 bit build error on
   Travis.
2016-12-29 17:52:38 +00:00
..
2016-12-29 17:52:38 +00:00
2015-12-23 17:29:53 -08:00
2016-12-29 17:52:38 +00:00
2016-05-21 12:51:11 -07:00
2016-10-08 10:51:19 -07:00
2016-12-29 17:52:38 +00:00
2016-02-14 22:21:50 -08:00
2015-09-15 07:46:09 -07:00
2015-09-15 07:46:09 -07:00
2015-09-15 07:46:09 -07:00

This contains the automated validation suite for the VM and built-in libraries.

  • benchmark/ - Performance tests. These aren't strictly pass/fail, but let us compare performance both against other languages and against previous builds of Wren itself.

  • core/ - Tests for the built in core library, mainly methods on the core classes. If a bug is in wren_core.c or wren_value.c, it will most likely break one of these tests.

  • language/ - Tests of the language itself, its grammar and runtime semantics. If a bug is in wren_compiler.c or wren_vm.c, it will most likely break one of these tests. This includes tests for the syntax for the literal forms of the core classes.

  • limit/ - Tests for various hardcoded limits. The language doesn't officially specify these limits, but the Wren implementation has them. These tests ensure that limit behavior is well-defined and tested.