Ignore the nonuapaottests category of XUnit tests
#1421
Conversation
|
@grendello should (can?) we do this only when the linker is enabled? Perhaps this is something I can handle only when testing a project configuration that enables the linker? I am not entirely sure that we should be skipping the entire category due to one test failure that occurs only when linking. |
We could wrap it in a Alternatively we handle this in the "calling" code, e.g. by setting the |
Either that or we could narrow it down a bit more. Introduce the
That should work too |
jonpryor
added
the
full-mono-integration-build
|
build |
|
Rebuilding with the full-mono-integration-build label set so that we build and run unit tests in the Release configuration, which should (hopefully) cause the assemblies to be linked. (They aren't linked in Debug). If the linker is removing the method, shouldn't that happen whenever the linker runes, i.e. Release, not just Release+AOT? Let's find out! |
|
As I feared/suspected, the @grendello: instead of using |
Fixes: dotnet#1400 Related: dotnet#1421 The mono/corefx xUnit test [`TaskSchedulerTests.GetTaskSchedulersForDebugger_ReturnsDefaultScheduler()`][0] [fails when built in Release mode][1]: [0]: https://github.com/dotnet/corefx/blob/893708a4c46047af6fb14bc0f2c33b3ca6adc527/src/System.Threading.Tasks/tests/TaskScheduler/TaskSchedulerTests.cs#L293-L301 [1]: https://jenkins.mono-project.com/view/Xamarin.Android/job/xamarin-android/980/testReport/junit/Test%20collection%20for%20System.Threading.Tasks.Tests/TaskSchedulerTests/System_Threading_Tasks_Tests_TaskSchedulerTests_GetTaskSchedulersForDebugger_ReturnsDefaultScheduler___Release/ System.NullReferenceException : Object reference not set to an instance of an object +++++++++++++++++++ STACK TRACE: at System.Threading.Tasks.Tests.TaskSchedulerTests.GetTaskSchedulersForDebugger_ReturnsDefaultScheduler () The cause is that the test grabs the `MethodInfo` for the `TaskScheduler.GetTaskSchedulersForDebugger()` method, which the linker removes -- correctly! as there are no references to it -- and the test then attempts to *invoke* the `MethodInfo`, but the `MethodInfo` is `null` (linked away!), resulting in the `NullReferenceException`. The test should be fixed, but in the meantime we can instead ignore the xUnit *category* of this test when building for Release.
Fixes: #1400 Related: #1421 The mono/corefx xUnit test [`TaskSchedulerTests.GetTaskSchedulersForDebugger_ReturnsDefaultScheduler()`][0] [fails when built in Release mode][1]: [0]: https://github.com/dotnet/corefx/blob/893708a4c46047af6fb14bc0f2c33b3ca6adc527/src/System.Threading.Tasks/tests/TaskScheduler/TaskSchedulerTests.cs#L293-L301 [1]: https://jenkins.mono-project.com/view/Xamarin.Android/job/xamarin-android/980/testReport/junit/Test%20collection%20for%20System.Threading.Tasks.Tests/TaskSchedulerTests/System_Threading_Tasks_Tests_TaskSchedulerTests_GetTaskSchedulersForDebugger_ReturnsDefaultScheduler___Release/ System.NullReferenceException : Object reference not set to an instance of an object +++++++++++++++++++ STACK TRACE: at System.Threading.Tasks.Tests.TaskSchedulerTests.GetTaskSchedulersForDebugger_ReturnsDefaultScheduler () The cause is that the test grabs the `MethodInfo` for the `TaskScheduler.GetTaskSchedulersForDebugger()` method, which the linker removes -- correctly! as there are no references to it -- and the test then attempts to *invoke* the `MethodInfo`, but the `MethodInfo` is `null` (linked away!), resulting in the `NullReferenceException`. The test should be fixed, but in the meantime we can instead ignore the xUnit *category* of this test when building for Release.
|
Superseded by PR #1630. |
3 participants
Fixes: #1400