daf5006281
* [msbuild] Add reference to `System.Drawing.Common.dll` to XI projects. Fixes https://github.com/mono/mono/issues/13483 : ``` @akoeplinger: Since we moved types from Mono.Android.dll and Xamarin.iOS/WatchOS/TVOS.dll to System.Drawing.Common.dll user projects would fail to compile. We need to add some msbuild logic to add a reference to the assembly automatically. ``` * [msbuild] Implement the same fix for XM projects as well. * [msbuild] Update Xamarin.iOS.Tasks.TargetTests.GetReferencedAssemblies_* tests. We're including a new assembly, which means the Xamarin.iOS.Tasks.TargetTests.GetReferencedAssemblies_* must be updated accordingly. Also modify these tests so that test assert that fails lists the actual assembly that's missing, i.e. instead of this: 1) Test Failure : Xamarin.iOS.Tasks.TargetTests.GetReferencedAssemblies_Executable #1 Expected: 6 But was: 7 we now print: 1) Test Failure : Xamarin.iOS.Tasks.TargetTests.GetReferencedAssemblies_Executable References Expected: equivalent to < "mscorlib.dll", "MyLibrary.dll", "System.Core.dll", "System.dll", "System.Xml.dll", "Xamarin.iOS.dll" > But was: < "mscorlib.dll", "MyLibrary.dll", "System.Core.dll", "System.dll", "System.Drawing.Common.dll", "System.Xml.dll", "Xamarin.iOS.dll" > * [tests] Adjust Xamarin.MMP.Tests.AssemblyReferencesTests.ShouldNotAllowReference_ToSystemDrawing. The test was verifying that referencing System.Drawing.dll and trying to use System.Drawing.RectangleF would fail to compile (because System.Drawing.dll shouldn't be resolved in this case). The addition of System.Drawing.Common.dll breaks this assumption, because now we ship System.Drawing.RectangleF, so the code that was supposed to fail to compile works just fine instead. So modify the test to verify that there's no System.Drawing.dll in the final bundle. * Remove workarounds for mono/mono#13483. * [msbuild] Create a way out if automatically referencing System.Drawing.Common.dll causes problems. * [msbuild] Adjust variable name and boolean logic according to review. |
||
|---|---|---|
| .. | ||
| 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 | ||
| 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