Figure out how to test generated UniFFI Desktop bindings

[linabutler]

As part of shipping UniFFI in Desktop “for real”, we’ll need to add unit tests for UniFFI itself, so we can verify that our serialization and code generation works correctly. For Swift, Kotlin, and Python, we have some scaffolding in the repo that runs all the examples as Rust tests on CircleCI.

This won’t really work for testing Gecko bindings (WebIDL or pure-C++)—because they depend on Gecko types, we basically need a full build of Firefox! On my souped-up 2018 MBP, a full build with a cold cache takes close to an hour. I don’t think it’s realistic for us to build Firefox on CircleCI just to test the binding generation.

Some ideas:

• Mock out the Gecko types—basically, check in fake implementations of nsString, nsTArray, Maybe, and so on, that use std::string, std::vector, std::optional, etc. under the hood—and link against those. These would build quickly, and we could then run UniFFI tests like any other language. The downside is, mocking out complicated core platform types means we have to worry about bugs in the mock...and we also have to keep our mocks up-to-date with Gecko in case they change.
• Somehow wire up UniFFI to TaskCluster, and make it so pushing to the UniFFI repo would kick off a hacked-up linux64 Try build on our infrastructure. I have no idea if this would even work.
• Vendor uniffi-bindgen into m-c, and run the tests as part of that. I have no idea how this would work, either, because UniFFI generates C++ files that need to get compiled into Firefox (so we need to run uniffi-bindgen before mach build), and then we need a runtime test (run during or after mach build) to make sure the serialization code works.

This feels like another thing we should capture in an ADR 😅

┆Issue is synchronized with this Jira Task
┆Issue Number: UNIFFI-20

[rfk]

I was recently wondering about the benefit of emitting some uniffi testcases as part of the generated code. This would mostly be useful for situations like the short-term plan for nimbus and m-c, where you want to checkin the generated bindings as part of your application, as the application could run the generated bindings testcases as part of its usual test suite.

There are probably plenty of downsides (code bloat and redundancy being the most obvious) but, figured I'd share the thought-bubble anyway.

[data-sync-user]

➤ Janet Dragojevic commented:

Possibly similar to glean - FOG - talk to them jan-erik or chutten

[rfk]

For additional reference, here are the Kotlin and Swift tests that are in a similar style to what we'd like to achieve. They use an example component that's specifically designed for testing:

• https://github.com/mozilla/uniffi-rs/tree/main/examples/rondpoint/tests/bindings

[rfk]

Clearing out some issues that we're not actively working on; I'm going to consolidate context on the Gecko bindings into a single new issue at #991