54f2dae935
This optimization can be enabled when it's not possible to use the managed linker (e.g. **Don't link**) or when the managed linker cannot remove references to deprecated types that would cause an application to be rejected by Apple. References to the existing types will be renamed, e.g. `UIWebView` to `DeprecatedWebView`, in every assemblies. The type definition is also renamed (for validity) and all custom attributes on the types and their members will be removed. Code inside the members will be replaced with a `throw new NotSupportedException ();`. The msbuild test app `MyReleaseBuild` has been updated to test that the optimization is working as expected (device builds are slow so reusing this test has little impact in test time). Basically the test ensure that `UIWebView` is used and cannot be removed by the compiler (optimization) or the managed linker (since it's referenced). Since the optimization is enabled then we can `grep` then final `.app` directory to ensure there's no mention of `UIWebView` inside any of the files that would be submitted. The application can be run, by itself, and will turn green if OK, red if `DeprecatedWebView` can't be found (skeleton replacement for `UIWebView`) or orange if a `NotSupportedException` is thrown. Finally introspection tests have been updated to skip over the deprecated (and renamed) types. It should not be an issue right now, since this optimization is not enabled by default, but it made testing easier. |
||
|---|---|---|
| .. | ||
| Mac | ||
| iOS | ||
| ApiAvailabilityTest.cs | ||
| ApiBaseTest.cs | ||
| ApiCMAttachmentTest.cs | ||
| ApiClassPtrTest.cs | ||
| ApiCoreImageFiltersTest.cs | ||
| ApiCtorInitTest.cs | ||
| ApiFieldTest.cs | ||
| ApiFrameworkTest.cs | ||
| ApiPInvokeTest.cs | ||
| ApiProtocolTest.cs | ||
| ApiSelectorTest.cs | ||
| ApiSignatureTest.cs | ||
| ApiStructTest.cs | ||
| ApiTypeTest.cs | ||
| ApiTypoTest.cs | ||
| ApiWeakPropertyTest.cs | ||
| CoreSelectorTest.cs | ||
| EnvironmentVariable.cs | ||
| README.md | ||
| xamarin1.png | ||
README.md
Introspection Tests
Introspection tests are executed on target (both simulator and device for iOS) or a specific version of OSX. The application proceed to analyze itself using:
System.Reflectionfor managed code; and- the ObjectiveC runtime library for native code
and compare the results. E.g. if using .NET reflection it can see a binding
for a NSBundle type then it should be able to find a native NSBundle
type using the ObjC runtime functions. Otherwise an error is raised...
Since the application analyze itself it must contains everything we wish to test. That's why the introspection tests needs to be built with the managed linker disable, i.e. "Don't link".
Pros
- The tests always tell the truth, which can differ from documentation or header files;
Cons
- Incomplete - Not everything is encoded in the metadata / executable;
- Too complete - Not every truth is good to be known (or published), which requires creating special cases in the tests