Provide (and document) an easy way to run tests on Apple Silicon

[nicoburns]

• I have searched existing issues and this is not a duplicate

Request

Provide, and clearly document an easy way to run yoga's test suite on Apple Silicon macs.

Context

• Apple Silicon macs are a popular platform. Especially for mobile developers who make up much of Yoga's audience.
• It is very difficult to work with and/or contribute to Yoga without being able to run the tests.
• This will likely require bypassing Buck as Buck does not currently run on Apple Silicon macs. The testing setup is based on gtest, so it should relatively straightforward to set it up so that it works in standalone manner. Unfortunately I lack the experience with the C/C++ build tool ecosystem to do this myself.

Alternatives

• Fix Buck to work on Apple Silicon. There is a partial PR here: Add support for M1 chips buck#2684

[NickGerleman]

Funnily the first way we got here is the development workflow for the JavaScript bindings, which run generated tests 🙂.

I’ve been doing a little bit of cleanup in preparation of changes to the CMake build. But the goal is:

1. The primary UT surface will be CMake + GTest (using ninja if available)
2. For most users with an available and non-ancient compiler toolchain, CMake will be the only dependency to install.
3. There will be a “build_and_test.sh” and “build_and_test.bat” which wrap CMake generation, CMake building a test binary (handling the GTest dependency), and running it. It will allow release vs debug builds, and pausing on start to allow attaching a debugger.
4. My eventual goal is to make an effort to consolidate the CMake logic between clang, MSVC, emscripten builds, of the different bindings. There will probably be more self contained CMake builds until I can figure out the best way to factor.
5. Generated tests should run on all of the bindings with a working build, along with any binding specific tests we already have.

[nicoburns]

This sounds great. CMake still seems like arcane magic to me (so any documentation/comments in the config files explaining things would be very welcome), but I understand that it's the closest thing to a standard build system for C/C++.

Generated tests should run on all of the bindings with a working build, along with any binding specific tests we already have.

I'd request to have the option to only run tests for one language (in particular the ability to only run the C tests). This will be important for quick iteration times when changing core algorithm code.

[NickGerleman]

The binding tests will be run either as PR validation, or if run explicitly. E.g. running yarn test from the JS root would run JS binding tests, or gradlew test in the Java root would run Java tests. C++ wise, there will be a script at the root of the Yoga repo to just run the C++ UTs.

[NickGerleman]

It's not 100% done yet but #1206 should implement all of this. Need to update more documentation, some MSVC bits, and split it up a bit before merging.

[nicoburns]

Seems to be working for me. I can run unit tests. I also managed to add a gentest and get the unit tests to fail. Although there were rough edges with this.

I added a style value that isn't currently supported by yoga (align-content: space-evenly), and this:

1. Caused the gentest script to crash halfway through.
2. When I commented out the non-cpp test generation, caused the entire file's worth of gentests to be overwritten with a blank file rather than just silently ignoring the style.

This was fixed by adding support for the style in the (javascript) gentest script after which I was able to get the test to generate correctly and then fail as expected.

[NickGerleman]

Yeah... the gentest script doesn't have great logging for when there is an exception in the browser. I've been wanting to take a sledgehammer to a lot of the script at some point. There are already too many different languages and toolchains in the repo, and the script is individually adding Ruby into the mix. So my ideal would be to convert to Node and also implement the changes for fixture expected failures and better managing Chrome behavior changes.

Speaking of, there are two fixtures broken by Chrome that I haven't merged a fix for yet. #1194 commented them out in the meantime (I'd just do the same if you haven't already), but I will need to rebase it.

FYI there should also be a VS Code debug target there for the unit tests, if you want to debug.

[nicoburns]

Using Node is a good idea. Then we could use puppeteer and eliminate the chromedriver dependency too.

and also implement the changes for fixture expected failures and better managing Chrome behavior changes.

Yeah, seems like it might good to have a way to define a test to take it's source of truth from a file rather than chrome on a case-by-case basis. But also, it would nice if Yoga had better feature flagging so that it could actually keep up with Chrome changes. "web compatible" vs. "yoga stable" modes or something (more fine grained control would be great, but I think just those two would make a good start).

[nicoburns]

Fixed by #1217