98b8ac8321
This will spot cases like https://github.com/xamarin/xamarin-macios/issues/7959 where a type (static) constructor can fail at runtime, leading to `TypeLoadException` Ideally it's covered by it's own tests but it's better covered twice than never :) On iOS 64bits [1] simulator we hit some failures [2], later, if the `.cctor` is executed. It's not a big deal to avoid those types since we it will be executed on devices later. [1] API not present on 32bits [2] Fixing the following triggers similar failures for `DCDevice` ``` ApiClassPtrTest.VerifyClassPtr: class_ptr and RegisterAttribute are different: NFCIso15693CustomCommandConfiguration Expected: 0 But was: 140735471513712 ApiSelectorTest.StaticMethods: 7 errors found in 2788 static selector validated: CoreNFC.NFCIso15693ReaderSession : readingAvailable CoreNFC.NFCNdefMessage : ndefMessageWithData: CoreNFC.NFCNdefPayload : wellKnownTypeURIPayloadWithString: CoreNFC.NFCNdefPayload : wellKnownTypeURIPayloadWithURL: CoreNFC.NFCNdefPayload : wellKnownTypeTextPayloadWithString:locale: CoreNFC.NFCNdefReaderSession : readingAvailable CoreNFC.NFCReaderSession : readingAvailable Expected: 0 But was: 7 ``` |
||
|---|---|---|
| .. | ||
| 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