<p>你的前两个问题很容易回答。只要可以避免,就不应该依赖于未记录的、特定于实现的行为。我想你可以避免在这里这样做。为了使这个答案更充实一点,我将花一些时间回答你的最后一个问题。在</p>
<blockquote>
<p>Is there a better way to do all this?</p>
</blockquote>
<p>第一步是确认您当前所写的是<a href="http://www.artima.com/weblogs/viewpost.jsp?thread=126923" rel="nofollow">not unit tests</a>。在</p>
<p>具体来说:</p>
<blockquote>
<p>A test is not a unit test if:</p>
<ul>
<li>It communicates across the network </li>
<li>It touches the file system </li>
</ul>
</blockquote>
<p>你的测试同时完成了这两项任务。这并不是说你的测试毫无价值,但重要的是要注意它们不是单元测试。这些测试的工作级别是<a href="http://en.wikipedia.org/wiki/Integration_testing" rel="nofollow">integration testing</a>。集成测试是:</p>
<blockquote>
<p>The phase in software testing in which individual software modules are
combined and tested as a group. It occurs after unit testing and
before validation testing</p>
</blockquote>
<p>我认为你的问题是你试图混合集成和单元测试的任务。在</p>
<p>在编写单元测试时,您希望每个测试依赖尽可能少的组件,并尽可能针对特定的情况。在您的例子中,这意味着在C#和Python中的测试都不依赖于另一个的输出。在这两个程序中,让序列化代码处理您需要它处理的最简单的情况,并验证您是否获得了所需的JSON加载/转储。这可能意味着在单元测试代码中以字符串的形式手工编写JSON(您希望您的测试足够小,这样就不会很痛苦)。在</p>
<p>对于您的集成测试,您只需要检查当您的不同部分相互通信时,没有什么会爆炸。在这里,您不必担心序列化和读取是否正确,因为您已经在单元测试中讨论过了。太好了!在</p>
<p>然后,如果遇到bug,修复它们并用适当的测试用例记录它们。最后,您应该有<em>批</em>的<em>小</em>单元测试和一个<em>少数</em>稍大的集成测试。在</p>