> OK.
>
> I am slightly concerned because we are now testing code in a different form
> from the one we deploy. In theory it shouldn't make any difference, but there
> are always edge cases.
Good point. The acceptance tests (at a minimum) should only use the libraries. (I'm perfectly happy for unit tests to link against the individual object files.)
A bit of investigation shows there is actually a real problem: lp:1349742
Having fixed that locally it looks like the "sticking points" are:
1. UsingStubClientPlatform (Uses MirConnection and MirWaitHandle directly)
2. mir::client::the_rpc_channel is used by test_protobuf.cpp
That's all stuff that could be reworked.
As the use of non-supported APIs in the acceptance tests is pre-existing I suggest I fix these in a follow-up MP.
> OK.
>
> I am slightly concerned because we are now testing code in a different form
> from the one we deploy. In theory it shouldn't make any difference, but there
> are always edge cases.
Good point. The acceptance tests (at a minimum) should only use the libraries. (I'm perfectly happy for unit tests to link against the individual object files.)
A bit of investigation shows there is actually a real problem: lp:1349742
Having fixed that locally it looks like the "sticking points" are:
1. UsingStubClient Platform (Uses MirConnection and MirWaitHandle directly)
2. mir::client: :the_rpc_ channel is used by test_protobuf.cpp
That's all stuff that could be reworked.
As the use of non-supported APIs in the acceptance tests is pre-existing I suggest I fix these in a follow-up MP.