单元测试的两种方式
在单元测试中，可通过两种方式来验证代码是否正确地工作。一种是基于结果状态的测试，一种是基于交互行为的测试。
测试结果与测试行为之间有什么区别呢？
基于结果状态的测试，也就意味着我们需要验证被测试代码需要返回正确的结果。
1 [TestMethod]
2 public void TestSortNumberResult()
3 {
4 IShellSorter<int> shellSorter = new ShellSorter<int>();
5 IBubbleSorter<int> bubbleSorter = new BubbleSorter<int>();
6
7 NumberSorter numberSorter = new NumberSorter(shellSorter, bubbleSorter);
8 int[] numbers = new int[] { 3, 1, 2 };
9 numberSorter.Sort(numbers);
10
11 // 验证返回值是否已经被正确排序。
12 // 只要返回值正确即可，并不关心使用了哪个算法。
13 CollectionAssert.AreEqual(new int[] { 1, 2, 3 }, numbers);
14 }
基于交互行为的测试，也就意味着我们需要验证被测试代码是否正确合理地调用了某些方法。
1 [TestMethod]
2 public void TestUseCorrectSortingAlgorithm()
3 {
4 IShellSorter<int> mockShellSorter = Substitute.For<IShellSorter<int>>();
5 IBubbleSorter<int> mockBubbleSorter = Substitute.For<IBubbleSorter<int>>();
6
7 NumberSorter numberSorter = new NumberSorter(mockShellSorter, mockBubbleSorter);
8 int[] numbers = new int[] { 3, 1, 2 };
9 numberSorter.Sort(numbers);
10
11 // 验证排序器是否使用冒泡排序算法。
12 // 如果排序器未使用冒泡排序算法，或者使用了该算法但传递了错误的参数，则验证失败。
13 mockBubbleSorter.Received().Sort(Arg.Is<int[]>(numbers));
14 }
第二种测试方法可能会得出较好的代码覆盖率，但它却没有告诉我们排序结果是否正确，而只是确认调用了 bubbleSorter.Sort() 方法。所以交互行为测试并不能证明代码可以正确工作。这也就是在大多数情况下，我们需要测试结果和状态，而不是测试交互和行为。
通常来说，如果程序的正确性不能仅仅靠程序的输出结果来决定，而还需要判断结果是怎么产生的，在这种条件下，我们就需要对交互和行为进行测试。在上面的示例中，你可能想在得到正确测试结果的前提下，额外的再测试下交互行为，因为可能确认正确地使用了某种算法非常重要，例如某些算法在给定条件下运行速度更快，否则的话测试交互行为的意义并不大。
通常在什么条件下需要对交互行为进行测试呢？
这里给出两种较适合的场景：
- 假设被测试代码需要调用了一个方法，但可能由于其被调用的次数不同，或者被调用的顺序不同，而导致产生了不同的结果，或者出现了其他类似时间延迟、多线程死锁等副作用。例如该方法负责发送邮件，我们需要确认只调用了一次邮件发送函数。或者例如该方法的不同调用顺序会产生不同的线程锁控制，导致死锁。在类似这些情况下，测试交互行为可以有效地帮助你确认方法调用是否正确。
- 假设我们在测试一个UI程序，其中已经通过抽象将UI渲染部分与UI逻辑部分隔离，可以考虑是某种MVC或MVVM模式。那么在我们测试 Controller 或 ViewModel 层时，如果有的话，可能只关心 View 上的哪些方法被调用了，而并不关系具体该方法内部是如何渲染的，所以此处测试与 View 的交互就比较合适。类似的，对于 Model 层也一样。
转载地址：
http://www.cnblogs.com/gaochundong/archive/2013/06/05/ut_test_state_or_test_interaction.html
http://www.cnblogs.com/gaochundong/archive/2013/05/22/nsubstitute_manual.html