As discussed here, the initial Linux Pigeon support has opaque host API response objects, which means that we can't easily write native unit tests against them the way we do all the other platforms, where we directly call the same API the Pigeon generated code and then check that the responses are correct. Testing that way has been very valuable on other platforms, because it's as close to end-to-end as we can get outside of integration tests (which aren't always possible), because there is no hand-written native code that we are skipping (as compared to, e.g., factoring out a helper which is called by the Pigeon API implementation, and testing that helper).

In the short term we can work around it by re-declaring the opaque struct in the unit test file, and then accessing it that way. This is obviously fragile to Pigeon updates, but having a short term solution where the only risk is that unit tests break on explicit Pigeon updates is not a big deal, and then we can add the APIs later and switch the unit tests to using those.

/cc @robert-ancell