现在，让我来解释一下列表2中的有关测试编码。该方法使用两个属性加以修饰。其中，第一个属性[TestMethod]标识此方法为一个测试方法，第二个属性[ExpectedException]则建立针对于该测试的一个期望。如果执行该测试方法的过程中不抛出一个ArgumentNullException型异常，那么该测试失败。我们之所以想使该测试抛出一个异常是因为我们想实现当Details页面所要求的ProductId参数不能满足时抛出一个异常。

   接下来，测试方法正文部分包含了两个语句。其中，第一个语句创建了ProductController类的一个实例，第二个语句调用控制器的Details()方法。

   值得注意的是，目前在我们的MVC应用程序中，我们还没有创建这个ProductController类。因此，这个测试不会成功执行。但是，这正是我们所期望实现的。很显然，当使用测试驱动思想进行开发时，这正体现了这种开发思想的重要特征。首先，你要编写一个将会失败的测试，然后，你再编写代码来进一步修改这个测试，再运行测试，再修改，……，直到通过测试。

   因此，让我们运行上面的这个测试—而且，我们将会得到期望的失败结果。注意到，在代码编辑器窗口的顶部应该有一个包含有两个按钮的工具栏。这两个按钮用于运行测试。其中，第一个按钮支持在当前上下文中运行当前测试，而第二个按钮能够在当前方案中运行所有的测试(见图4)。



   图4—使用Visual Studio 2008测试工具栏

   现在，我们来详细分析一下点击这两个按钮有什么不同效果。在当前上下文运行测试将执行不同的测试依赖于你的鼠标光标在代码编辑器窗口中所在的位置。如果你的鼠标光标位于一个特定的测试方法中，那么将仅仅执行此方法。如果你的鼠标光标位于整个测试类中，那么该测试类中所有的测试都将被执行。如果当前焦点位于测试结果窗口中，那么将执行所有的测试（有关细节，请参考http://blogs.msdn.com/nnaderi/archive/2007/05/11/new-unit-testing-features-in-orcas-part-1.aspx）。

   实际上，我建议你应该总是努力避免使用鼠标点击按钮的方式。一方面，点击按钮速度太慢；另一方面，测试驱动开发要求所有执行测试过程必须相当迅速。因此，我推荐你使用下列这些组合键来执行测试：

   Ctrl-R，A—运行方案中的所有测试
   Ctrl-R，T—运行当前上下文中的所有测试
   Ctrl-R，N—运行当前命名空间中的所有测试
   Ctrl-R，C—运行当前类中的所有测试
   Ctrl-R，Ctrl-A—调试方案中的所有测试
   Ctrl-R，Ctrl-T—调试当前上下文中的所有测试
   Ctrl-R，Ctrl-N—调试当前命名空间中的所有测试
   Ctrl-R，Ctrl-C—调试当前类中的所有测试

   如果你使用Ctrl-R，A组合键运行我们刚刚创建的测试方法，那么它将失败。该测试甚至不会编译成功，因为我们还没有创建ProductController类或一个Details()方法。这正是我们接下来要做的。

   切换回到ASP.NET MVC工程，使用鼠标右击Controllers文件夹，然后选择“Add→New Item”。选择Web类型并且选择MVC控制器类。把新的控制器命名为ProductController并且点击“Add”按钮(或仅仅按一下回车键)。于是，创建一个包括一个Index()方法的新的控制器。

   现在，我们想编写尽可能少的代码仅使我们的单元测试运行通过就行。列表3中的ProductController类将能够通过我们的单元测试。

   列表3—ProductController.cs
 

   在此，列表3中的类ProductController包含一个方法名字为Details()。请注意，在此我略去了当你创建一个新的控制器时默认生成的Index()方法。于是，上面的Details()方法总是抛出一个ArgumentNullException异常。 

   在输入列表3中的代码后，按下键盘上的组合键Ctrl-R，A(你不需要切换回测试工程运行测试)。图5展示了我们的测试成功时的测试结果窗口。



                  图5—成功通过测试的绿色对号提示

   你可能会认为，你不是疯了吧？没错，当前情况下，我们的Details()方法总是抛出一个异常。在此，再次提醒你注意测试驱动开发的基本思想：目前情况下，你仅需专注于满足你的测试要求就行。以后的测试将迫使你进一步构建一个更为符合实际要求的控制器方法。