通用的示例说明：
- 本系列博客只讨论工具的基础，不讨论任何语言。
- 甚至不讨论快捷键:-)
- 可以用鼠标就完成本教程
- IDE默认指代的是Visual Studio 2013 Community Edition。 本系列文章的结尾，你可以熟练地使用它写程序。
- 将Visual Studio启动后的默认布局状态称为主窗口,主窗口标题栏中显示的项目名称不必要。
- 在日常口语和Windows资源管理器的基础上定义了几个描述菜单操作的符号：[]、{}、/、>>、=、(,)。
- 检查一个设置项的表示方法为:
- [窗口名称]/{菜单名称}/{子菜单名称}/{设置项项名称}=设置项的值
- 例如默认的Debug配置:
- [主窗口]/{解决方案配置管理器}=Debug
- 检查多个设置项时，按照单个设置项的方式，逐一写出
- 检查一个设置项有多个值的时候，用括号包括并用内部的逗号分隔，如:
- [解决方案资源管理器]/{项目名称}/{引用}=(System,System.Core,System.Data,System.Xml)
- 执行一个左键单击序列，就是将最后的检查项换成”/”，例如退出IDE:
- [主窗口]/{文件}/{退出}/
- 右键菜单的连接符号为>>，例如刷新Windows桌面:
- [桌面]>>{刷新}/
- 弹出窗口中的设置项的表示与上类似
- MDI子窗口中设置项的表示与上类似，注意到在Visual Studio中，MDI子窗口的名称在它的左上角或者可能自动吸附到主窗口的四周
- 标题栏和状态栏作为菜单的推广，适用于上述表示方法
- 缺陷说明
- 欢迎反馈，mailto:[email protected]
- 作者的首选语言是C#
- 作者是软狗
- 作者的IDE没装中文语言包，所以有的名词翻译得不准确:-(
- 由于还没有厘清相关的证书问题，版权保留
- 系列文章没有提出或解决新的问题，目的只是科普
正文
第一，测试先行
测试先行至少代表了两个好的实践：一是在后续的工作中可以专心于编写程序之上；第二更加深层的理由是接口已经稳定。接口与实现的辩证关系是这样的，“脏” 代码总是从接口和实现都不稳定的编程开始的。接口和实现都稳定的肯定不是编程，而是产品。接口稳定而实现不稳定的代码还有改善的可能，而接口不稳定的代码基本上难以推进工作。总之，不应该在接口不稳定的情况下开始写代码。
源代码与代码片段之间最大的区别在于，源代码可以在一段时间以内保持稳定，因为源代码是充分测试过的。一般的示例只能说明原理，用作代码片段，而不能作为源代码。
测试先行不代表首先创建测试项目。相反，应该先创建项目”项目1”，然后再创建项目”项目1Test”。逻辑上的顺序是这样的:先确定项目的类型，其次确定项目的接口，然后根据接口编写测试项目的内容，最后进入”编码——测试”的反复循环，直到写出了能够通过测试的代码。至此又开始另一个”项目X”的工作。
第二，单元测试
单元测试是最简单而且最有必要的测试。Visual Studio已经集成了很好的单元测试实践，让我们开始吧:-)
[主窗口]/{文件}/{新建}/{项目}/
[新建项目]/{单元测试项目}/
[新建项目]/解决方案=添加到当前解决方案
[新建项目]/OK/
这样，我们的解决方案当中有了一个新的测试项目。可以发现测试项目的引用非常简单。在引用处添加对需要测试的项目的引用，就可以开始编写测试函数了。
运行测试项目的方法是：
[主窗口]/{测试}/{运行}/{所有测试}/
这会弹出测试资源管理器，告诉用户在测试函数执行过程中出现的问题。值得注意的是，自始至终，不推荐为每一个测试单独再编写main()方法，因为main()方法对应的控制台应用程序是一个系统的前端。当然，编写专门的控制台应用程序来进行全部测试也是不错的。
第三，测试和调试的区别
最直观的区别在于，调试就是检查断点处的状态是否符合预期，测试就是看整体上的行为是否符合预期。调试的目的是确保正确的实现，着重接口的内部实现，通常不需要借助专门的外部代码。测试的目的是要集中精力去实现，着重接口的外部行为，要借助专门的外部代码。有的测试还需要借助外部的测试集（可以理解成一个txt文件）来进行。
第四，测试的代码质量
测试还有一个可爱的好处是，测试代码的要求没有正式代码那么苛刻:-)。通常可以借用一些教科书或者官方的示例代码。
第五，编程中精力的分配
测试的智慧在于集中。测试从工序上说，是先用一小段时间确定了测试方法，然后用一大段时间去编写实际工作的代码。它避免了开发人员同时写业务代码和验证代码的尴尬。因此，可以说测试的好处在于让开发人员将精力集中到实现上去。
不仅如此，测试确保了整个开发工作围绕接口来进行，有利于复用和升级。
总结
使用Visual Studio完成的测试只能作为用户了解软件工程的一个开始，但是”在一段时间以内专注地进行编程”而不是写一大堆难以控制的main方法这个方法论是值得保持的。