MSpec Json.NET 反序列化测试在 ReSharper 中失败但在 NCrunch 中通过
MSpec Json.NET deserialization test fails in ReSharper but passes in NCrunch
我有以下两个单元测试：一个使用 MSTest，一个使用机器规范。据我所知，它们的行为应该相同。然而，虽然第一个在 NCrunch 和 ReSharper 测试运行器中都通过了，但第二个在 ReSharper 中失败了。
using Machine.Specifications;
using Microsoft.VisualStudio.TestTools.UnitTesting;
using Newtonsoft.Json;
public class TestModel
{
public string Name { get; set; }
public int Number { get; set; }
}
// MSTest
[TestClass]
public class DeserializationTest
{
[TestMethod]
public void Deserialized_object_is_the_same_type_as_the_original()
{
TestModel testModel = new TestModel() {Name = "John", Number = 42};
string serialized = JsonConvert.SerializeObject(testModel, new JsonSerializerSettings { TypeNameHandling = TypeNameHandling.Objects });
object deserialized = JsonConvert.DeserializeObject(serialized, new JsonSerializerSettings { TypeNameHandling = TypeNameHandling.Objects });
// This passes in both test runners
Assert.IsInstanceOfType(deserialized, typeof(TestModel));
}
}
// MSpec
public class When_an_object_is_deserialized
{
static TestModel testModel;
static string serialized;
static object deserialized;
Establish context = () =>
{
testModel = new TestModel() { Name = "John", Number = 42 };
serialized = JsonConvert.SerializeObject(testModel, new JsonSerializerSettings { TypeNameHandling = TypeNameHandling.Objects });
};
Because of = () => deserialized = JsonConvert.DeserializeObject(serialized, new JsonSerializerSettings { TypeNameHandling = TypeNameHandling.Objects });
// This passes in NCrunch but fails in ReSharper.
It should_be_the_same_type_as_the_original = () => Assert.IsInstanceOfType(deserialized, typeof(TestModel));
}
失败消息是：Assert.IsInstanceOfType failed. Expected type:<UnitTestProject2.TestModel>. Actual type:<UnitTestProject2.TestModel>.奇怪的是，以下确实通过了：
It should_be_the_same_type_as_the_original = () => Assert.IsTrue(testModel.GetType() == typeof(TestModel));
我以这种方式进行反序列化，因为有问题的实际代码需要能够处理直到运行时类型未知的对象。我认为 Json.NET 进行这种反序列化的方式有些奇怪，但为什么两个测试运行器的行为会有所不同？我在 Visual Studio 2013 年使用 ReSharper 9.1。
显然，由于 NCrunch 和 ReSharper 之间的一些细微行为差异，运行时会产生奇怪的影响。失败肯定是在告诉您出了什么问题，您不应该将其视为 ReSharper 或 NCrunch 中的错误。
当我在调试器中单步执行 MSpec 测试时，deserialized 对象在调试器中显示以下错误：
deserialized Cannot fetch the value of field 'deserialized' because information about the containing class is unavailable. object
如果没有看到您的完整解决方案，很难确定，但我已经看到当构建输出目录包含一个程序集的多个副本（可能在子目录中）时会发生这种情况。如果不同组件在不同时间引用程序集的不同副本，则程序集的类型有时会被视为不相等，即使它实际上是程序集的相同副本。解决方案是确保您的构建输出中只有每个程序集的一个副本，以确保所有内容都引用完全相同的文件。可能是 JSON 转换器正在动态加载您的类型并获取错误的程序集，或者可能将其加载到不同的加载上下文中，这意味着它的类型不被视为与在不同上下文中加载的副本相等。
在 MSpec 案例中，您的构建环境可能会导致程序集的重复副本。特别是 NCruch，默认情况下不执行 post-build 事件（通常会显示警告），因此如果您在 post-build 步骤中复制文件，那么可能是对不同行为的一种解释。您可以通过在 NCrunch 中启用 post-build 事件并查看是否发生故障来检查。
另一个可能的故障排除步骤是使用 Fusion 日志查看器 (fuslogvw.exe) 记录程序集绑定，您应该能够准确计算出正在加载哪些程序集以及在什么加载上下文中。
更新
我很确定这是由 JSON 转换器在运行时使用程序集引起的程序集绑定问题。在融合日志中，我找到了这个条目：
*** Assembly Binder Log Entry (05/06/2015 @ 02:01:38) ***
The operation was successful.
Bind result: hr = 0x0. The operation completed successfully.
Assembly manager loaded from: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll
Running under executable C:\Users\Tim\AppData\Local\JetBrains\Installations\ReSharperPlatformVs12_001\JetBrains.ReSharper.TaskRunner.CLR45.x64.exe
--- A detailed error log follows.
LOG: IJW explicit bind. File path:c:\users\tim\VS-Projects\Whosebug\Whosebug.30643046\bin\Debug\Whosebug.30643046.dll.
LOG: IJW assembly bind returned a different path: C:\Users\Tim\AppData\Local\Temp\k3dpwn5u.uii\Machine Specifications Runner\assembly\dl3c41c492\c7eea8ec_279fd001\Whosebug.30643046.dll. Use the file provided.
我也找到了这个：
*** Assembly Binder Log Entry (05/06/2015 @ 02:01:38) ***
The operation was successful.
Bind result: hr = 0x0. The operation completed successfully.
Assembly manager loaded from: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll
Running under executable C:\Users\Tim\AppData\Local\JetBrains\Installations\ReSharperPlatformVs12_001\JetBrains.ReSharper.TaskRunner.CLR45.x64.exe
--- A detailed error log follows.
WRN: The same assembly was loaded into multiple contexts of an application domain:
WRN: Context: Default | Domain ID: 2 | Assembly Name: Whosebug.30643046, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null
WRN: Context: Neither | Domain ID: 2 | Assembly Name: Whosebug.30643046, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null
WRN: This might lead to runtime failures.
WRN: It is recommended to inspect your application on whether this is intentional or not.
WRN: See whitepaper http://go.microsoft.com/fwlink/?LinkId=109270 for more information and common solutions to this issue.
*** Assembly Binder Log Entry (05/06/2015 @ 02:04:41) ***
The operation was successful.
Bind result: hr = 0x0. The operation completed successfully.
Assembly manager loaded from: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll
Running under executable C:\Users\Tim\AppData\Local\JetBrains\Installations\ReSharperPlatformVs12_001\JetBrains.ReSharper.TaskRunner.CLR45.x64.exe
--- A detailed error log follows.
WRN: The same assembly was loaded into multiple contexts of an application domain:
WRN: Context: Default | Domain ID: 2 | Assembly Name: Whosebug.30643046, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null
WRN: Context: Neither | Domain ID: 2 | Assembly Name: Whosebug.30643046, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null
WRN: This might lead to runtime failures.
WRN: It is recommended to inspect your application on whether this is intentional or not.
WRN: See whitepaper http://go.microsoft.com/fwlink/?LinkId=109270 for more information and common solutions to this issue.
*** Assembly Binder Log Entry (05/06/2015 @ 02:04:42) ***
The operation was successful.
Bind result: hr = 0x0. The operation completed successfully.
Assembly manager loaded from: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll
Running under executable C:\Users\Tim\AppData\Local\JetBrains\Installations\ReSharperPlatformVs12_001\JetBrains.ReSharper.TaskRunner.CLR45.x64.exe
--- A detailed error log follows.
WRN: The same assembly was loaded into multiple contexts of an application domain:
WRN: Context: Default | Domain ID: 2 | Assembly Name: Whosebug.30643046, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null
WRN: Context: Neither | Domain ID: 2 | Assembly Name: Whosebug.30643046, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null
WRN: This might lead to runtime failures.
WRN: It is recommended to inspect your application on whether this is intentional or not.
WRN: See whitepaper http://go.microsoft.com/fwlink/?LinkId=109270 for more information and common solutions to this issue.
我还发现禁用 ReSharper 单元测试选项 "Shadow copy assemblies being tested" 会导致测试通过。
所以我认为我们有 'smoking gun'。由于您让 JSON 反序列化器在运行时发现类型的方式，您的程序集加载存在冲突。
更新 2015-06-11
我注意到了this on the MSpec mailing list, it might be relevant to your issue: [machine.specifications] Shadow copying broken - creates very subtle bugs in tests
如@tim-long 所述，此问题（和 MSpec #278）的原因是 MSpec 运行ner 中的错误。该错误是由 ReSharper 设置为卷影复制测试程序集（默认情况下为 "on"）触发的。
Json.NET 的 TypeNameHandling.Objects 选项导致程序集加载 按程序集名称 ，因此使用影子复制测试程序集加载 TestModel 类型，不同于 MSpec 运行ner 用于加载的非影子复制版本和 运行 测试程序集。这会导致“预期类型：。实际类型： ”失败。有关详细信息，请参阅 #279 为什么在启用卷影复制的情况下加载测试程序集两次。
我能够重现此故障并检查我的修复 #279 是否也解决了此问题。
我有以下两个单元测试：一个使用 MSTest，一个使用机器规范。据我所知，它们的行为应该相同。然而，虽然第一个在 NCrunch 和 ReSharper 测试运行器中都通过了，但第二个在 ReSharper 中失败了。
using Machine.Specifications;
using Microsoft.VisualStudio.TestTools.UnitTesting;
using Newtonsoft.Json;
public class TestModel
{
public string Name { get; set; }
public int Number { get; set; }
}
// MSTest
[TestClass]
public class DeserializationTest
{
[TestMethod]
public void Deserialized_object_is_the_same_type_as_the_original()
{
TestModel testModel = new TestModel() {Name = "John", Number = 42};
string serialized = JsonConvert.SerializeObject(testModel, new JsonSerializerSettings { TypeNameHandling = TypeNameHandling.Objects });
object deserialized = JsonConvert.DeserializeObject(serialized, new JsonSerializerSettings { TypeNameHandling = TypeNameHandling.Objects });
// This passes in both test runners
Assert.IsInstanceOfType(deserialized, typeof(TestModel));
}
}
// MSpec
public class When_an_object_is_deserialized
{
static TestModel testModel;
static string serialized;
static object deserialized;
Establish context = () =>
{
testModel = new TestModel() { Name = "John", Number = 42 };
serialized = JsonConvert.SerializeObject(testModel, new JsonSerializerSettings { TypeNameHandling = TypeNameHandling.Objects });
};
Because of = () => deserialized = JsonConvert.DeserializeObject(serialized, new JsonSerializerSettings { TypeNameHandling = TypeNameHandling.Objects });
// This passes in NCrunch but fails in ReSharper.
It should_be_the_same_type_as_the_original = () => Assert.IsInstanceOfType(deserialized, typeof(TestModel));
}
失败消息是：Assert.IsInstanceOfType failed. Expected type:<UnitTestProject2.TestModel>. Actual type:<UnitTestProject2.TestModel>.奇怪的是，以下确实通过了：
It should_be_the_same_type_as_the_original = () => Assert.IsTrue(testModel.GetType() == typeof(TestModel));
我以这种方式进行反序列化，因为有问题的实际代码需要能够处理直到运行时类型未知的对象。我认为 Json.NET 进行这种反序列化的方式有些奇怪，但为什么两个测试运行器的行为会有所不同？我在 Visual Studio 2013 年使用 ReSharper 9.1。
显然，由于 NCrunch 和 ReSharper 之间的一些细微行为差异，运行时会产生奇怪的影响。失败肯定是在告诉您出了什么问题，您不应该将其视为 ReSharper 或 NCrunch 中的错误。
当我在调试器中单步执行 MSpec 测试时，deserialized 对象在调试器中显示以下错误：
deserialized Cannot fetch the value of field 'deserialized' because information about the containing class is unavailable. object
如果没有看到您的完整解决方案，很难确定，但我已经看到当构建输出目录包含一个程序集的多个副本（可能在子目录中）时会发生这种情况。如果不同组件在不同时间引用程序集的不同副本，则程序集的类型有时会被视为不相等，即使它实际上是程序集的相同副本。解决方案是确保您的构建输出中只有每个程序集的一个副本，以确保所有内容都引用完全相同的文件。可能是 JSON 转换器正在动态加载您的类型并获取错误的程序集，或者可能将其加载到不同的加载上下文中，这意味着它的类型不被视为与在不同上下文中加载的副本相等。
在 MSpec 案例中，您的构建环境可能会导致程序集的重复副本。特别是 NCruch，默认情况下不执行 post-build 事件（通常会显示警告），因此如果您在 post-build 步骤中复制文件，那么可能是对不同行为的一种解释。您可以通过在 NCrunch 中启用 post-build 事件并查看是否发生故障来检查。
另一个可能的故障排除步骤是使用 Fusion 日志查看器 (fuslogvw.exe) 记录程序集绑定，您应该能够准确计算出正在加载哪些程序集以及在什么加载上下文中。
更新 我很确定这是由 JSON 转换器在运行时使用程序集引起的程序集绑定问题。在融合日志中，我找到了这个条目：
*** Assembly Binder Log Entry (05/06/2015 @ 02:01:38) *** The operation was successful. Bind result: hr = 0x0. The operation completed successfully. Assembly manager loaded from: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll Running under executable C:\Users\Tim\AppData\Local\JetBrains\Installations\ReSharperPlatformVs12_001\JetBrains.ReSharper.TaskRunner.CLR45.x64.exe --- A detailed error log follows. LOG: IJW explicit bind. File path:c:\users\tim\VS-Projects\Whosebug\Whosebug.30643046\bin\Debug\Whosebug.30643046.dll. LOG: IJW assembly bind returned a different path: C:\Users\Tim\AppData\Local\Temp\k3dpwn5u.uii\Machine Specifications Runner\assembly\dl3c41c492\c7eea8ec_279fd001\Whosebug.30643046.dll. Use the file provided.
我也找到了这个：
*** Assembly Binder Log Entry (05/06/2015 @ 02:01:38) *** The operation was successful. Bind result: hr = 0x0. The operation completed successfully. Assembly manager loaded from: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll Running under executable C:\Users\Tim\AppData\Local\JetBrains\Installations\ReSharperPlatformVs12_001\JetBrains.ReSharper.TaskRunner.CLR45.x64.exe --- A detailed error log follows. WRN: The same assembly was loaded into multiple contexts of an application domain: WRN: Context: Default | Domain ID: 2 | Assembly Name: Whosebug.30643046, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null WRN: Context: Neither | Domain ID: 2 | Assembly Name: Whosebug.30643046, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null WRN: This might lead to runtime failures. WRN: It is recommended to inspect your application on whether this is intentional or not. WRN: See whitepaper http://go.microsoft.com/fwlink/?LinkId=109270 for more information and common solutions to this issue. *** Assembly Binder Log Entry (05/06/2015 @ 02:04:41) *** The operation was successful. Bind result: hr = 0x0. The operation completed successfully. Assembly manager loaded from: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll Running under executable C:\Users\Tim\AppData\Local\JetBrains\Installations\ReSharperPlatformVs12_001\JetBrains.ReSharper.TaskRunner.CLR45.x64.exe --- A detailed error log follows. WRN: The same assembly was loaded into multiple contexts of an application domain: WRN: Context: Default | Domain ID: 2 | Assembly Name: Whosebug.30643046, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null WRN: Context: Neither | Domain ID: 2 | Assembly Name: Whosebug.30643046, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null WRN: This might lead to runtime failures. WRN: It is recommended to inspect your application on whether this is intentional or not. WRN: See whitepaper http://go.microsoft.com/fwlink/?LinkId=109270 for more information and common solutions to this issue. *** Assembly Binder Log Entry (05/06/2015 @ 02:04:42) *** The operation was successful. Bind result: hr = 0x0. The operation completed successfully. Assembly manager loaded from: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll Running under executable C:\Users\Tim\AppData\Local\JetBrains\Installations\ReSharperPlatformVs12_001\JetBrains.ReSharper.TaskRunner.CLR45.x64.exe --- A detailed error log follows. WRN: The same assembly was loaded into multiple contexts of an application domain: WRN: Context: Default | Domain ID: 2 | Assembly Name: Whosebug.30643046, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null WRN: Context: Neither | Domain ID: 2 | Assembly Name: Whosebug.30643046, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null WRN: This might lead to runtime failures. WRN: It is recommended to inspect your application on whether this is intentional or not. WRN: See whitepaper http://go.microsoft.com/fwlink/?LinkId=109270 for more information and common solutions to this issue.
我还发现禁用 ReSharper 单元测试选项 "Shadow copy assemblies being tested" 会导致测试通过。
所以我认为我们有 'smoking gun'。由于您让 JSON 反序列化器在运行时发现类型的方式，您的程序集加载存在冲突。
更新 2015-06-11
我注意到了this on the MSpec mailing list, it might be relevant to your issue: [machine.specifications] Shadow copying broken - creates very subtle bugs in tests
如@tim-long 所述，此问题（和 MSpec #278）的原因是 MSpec 运行ner 中的错误。该错误是由 ReSharper 设置为卷影复制测试程序集（默认情况下为 "on"）触发的。
Json.NET 的 TypeNameHandling.Objects 选项导致程序集加载 按程序集名称 ，因此使用影子复制测试程序集加载 TestModel 类型，不同于 MSpec 运行ner 用于加载的非影子复制版本和 运行 测试程序集。这会导致“预期类型：
我能够重现此故障并检查我的修复 #279 是否也解决了此问题。