终于到了我们这个SharePoint可连续集成系列的最后一篇。今天我们先总结从有关于产品运行测试这个主题，然后主要调论一下代码的品质。特别是，我们将看看如何使用build生成过程对我们的代码进行几种形式的分析的方法，如SPDisposeCheck和VisualStudio代码分析工具。

在Build中运行单元/综合测试

在上次发表的博客中，运行测试作为build的一部分，我展示了VisualStudio Coded UI Tests怎样集成到产品中去验证它的质量。因为之前没有提及，有一些在SharePoint版本中运行的单元测试的注意事项还是值得一提的；当然，单元测试可以提供与编码UI测试同等或更大的价值，最终推荐使用混合几种测试类型的测试方法。这里有个警告——因为SharePoint2010是运行在.NET3.5上，而TeamFoundation Server 2010 Team Build是运行在.Net 4上，所以使用单元测试在一个自动化的版本中调用SharePointAPI是行不通的。那些测试通常被称为集成测试。

下面的表格给出一些总结：

集成测试可以在一个既有TFS版本代理又安装了SharePoint2010的版本服务器上工作，但是我们不推荐这种配置。

需要记住的是这种警告之应用于自动化的版本。当然单元测试和集成测试是可以手动地在VisualStudio 2010中，只要你安装了Visual Studio 2010Service Pack 1 并且修改下Visual Studio配置信息即可。更多信息请参看SharePoint2010 与单元测试

说完了上面那些，我们来看看SPDisposeCheck和CodeAnalysis(代码分析)。

将SPDisposeCheck集成进build中

如果你对SPDisposeCheck不熟，这里简单解释一下，它是微软出品的软件用于扫描对象处理相关问题的自定义SharePoint代码——这些问题可能会导致严重的性能问题，使用该工具被认为是最佳实践。在Build中集成这样的工具往往可以帮助我们把工作做得很好，因为它意味着单独的开发人员不需要记着要手动运行这个工具。但是，首先build中的测试运行有一个注意事项。因为SPDisposeCheck是一个命令行可执行文件，它可以很容易的集成到build中。因为你可能还记得一些将WSP算作为自动化Build的一部分部署，我们可以使用TFSbuild工作流中的InvokeProcess活动去调用一个外部进程。这样的话，我们真正要做的就是拖动一个InvokeProcess活动到工作流设计图面，然后配置SPDisposeCheck.exe的安装路径和可寻的输出程序集的位置。

集成SPDisposeCheck——进程

这有一些详细步骤：

1．在build服务器上安装SPDisposeCheck （如：服务器上运行着TFSbuild代理——这可能会有多个如果你扩展了这个角色）。我们需要记录一下可执行程序的安装路径——默认情况下，安装程序将使用C:\Program Files (x86)\Microsoft\SharePoint DisposeCheck\SPDisposeCheck.exe。

2．在TFS源代码管理工具中，打开这个XAML文件，它表示您从BuildProcessTemplate文件夹开始的程序构建进程。双击文件，打开Visual Studio工作流设计工具。

3．在工作流中找一个合适的地方运行SPDisposeCheck。在编译步骤之后我们需要这个地方，因为我们需要输出目录中创建的程序集。为简单起见，考虑在任意自定义步骤中的相同位置实施这些构建模板的修改，如在部署WSP包以前。

4．拖动一个Sequence活动。重命名显示名称如“SPDisposeCheck”。

5．在Sequence里面，拖动一个InvokeProcess活动。重命名显示名称如“运行SPDisposeCheck”.

6．[可选]定义一个整数变量，以收集SPDisposeCheck返回的故障数目。应该做如下配置：

7．配置InvokeProcess活动。FileName的属性应该为build代理中SPDisposeCheck.exe的位置，以及Arguments属性应该为outputDirectorybuild变量，被引号包裹着。此外，如果我们在第六步定义这个整数变量，那么Result属性应该如下所示：

8．给InvokeProcess活动添加一个日志活动，这样任何SPDisposeCheck的消息输出都可以显示在构建报告里。拖动一个WriteBuildMessage活动来截取stdOutput变量，和一个WriteBuildError活动来截取二人Output变量。

未经配置                    配置过后

9．编辑WriteBuildMessage活动的属性——修改重要属性为BuildMessageImportance.High. 如果不这么设置，SPDisposeCheck的消息就无法默认写入到构建报告中。

10．[可选的]如果SPDisposeCheck发现问题，则写一个警告信息到构建总结里。

a. 在InvokeProcess活动调用SPDisposeCheck后立即添加一个”If” 活动。修改Condition（条件）属性为一个验证是否整数变量（在第六步创建）大于等于零的表达式。看起来是这样的”SPDisposeCheckResult> 0”.

b. 在“If”活动中，拖动一个WriteBuildWarning活动。编辑Message（消息）属性记录SPDiposeCheck爆出的问题数量。看起来是这样的String.Format(“SPDisposeCheck reported {0} issues – theseshould be investigated.”, SPDisposeCheckResult)

11．保存和嵌入构建进程模板文件中。

整合SPDisposeCheck——结果

当一个版本运行的时候，这个版本的报告会包含一些SPDisposeCheck跨越几个已建立的程序集的执行细节的分析。由于SPDisposeCheck写入到控制台，我们WriteBuildMessage活动将借此输出，将它添加到构建日志：

如果你做了这个可选的步骤在构建总结中写一个警告信息，我们可以在构建的总结视图中看到它（在进入详细日志之前）：

在build中使用代码分析

其他工具一样，开发人员可以手动运行，但可能会忘记的是，代码分析也非常适合可持续性集成。代码分析是Visual Studio 2010（Premium或以上版本）的功能，它会检查代码是否遵守良好的规则，包括那些存档了的NET Framework准则。Microsoft提供了几个代码分析规则集来检查代码的不同问题，为了在分析进程上掌握所有控制权，它也可以创建自定义规则集和压制个人的规则。对于这个功能，我的经验是，虽然需要一些调整，通常对我们是有益的，即使是熟练的开发人员也可以借助工具有效的发现他们的代码中以前没有注意到的问题。

启用代码分析——过程

这里是详细步骤：

1． 编辑build定义，并且在“Process”（进程）选项卡上，找到“Perform Code Analysis”（执行代码分析）选项。设置为“Always”（始终）或者“AsConfigured”（看配置而定）——使用后者意味着每个人的Visual Studio项目都将会被考虑。

2． 使用构建定义列出一个新build。当构建完成，构建报告和可能包含了很多主要关于SharePoint程序集的CA0060错误。每一个CA0060错误的描述与下述类似“找不到间接引用程序集[程序集细节]。该程序集没有被分析，分析结果不完整。”如下图所示：

3． 为构建服务器添加漏掉的程序集。当代码分析应该是运行成功，尽管有CA0060的错误（任何问题都应该在构建报告中显示）的时候，我们强烈建议对这些由CA0060错误引起的“噪音”进行处理。要处理它，将每一个有CA0060错误的程序集拷贝到运行有TFS构建代理服务的服务器上。程序集可以从SharePoint2010 服务器的GAC中复制——这些应该被添加到以及包含其它SharePoint程序集的构建服务器的目录下。如果你想使用微软提供的存档在为你的SharePoint项目创建第一个TFS构建进程的SharePointProjectToTfsBuildServer.ps1 PowerShell脚本，那么这个位置应为‘C:\Program Files (x86)\ReferenceAssemblies\Microsoft\SharePoint14’。

4．重启TFS构建服务。确认没有版本在运行，然后再TFS服务器上打开TeamFoundation Server管理控制台。在“Build Configuration”（构建配置）视图中，对相应的构建服务使用“Restart”（重启）连接：

5．用排队等待中的新build来测试改变。构建报告中应高只有有效的代码分析，不会有CA0060错误的噪音：

总结

一旦实现自动构建，他们就为“在后台”自动运行的进程提供了很大的便利，否则开发人员必须手动去运行。在真实世界的条件下，将提供一个很大的优点因为个人开发者不需要在编码时周期性的运行这样的工具。除此之外，自动构建将永远不会忘记这些任务。

在这边文章里我们向大家展示了如何在构建进程中引入SPDisposeCheck以及VisualStudio代码分析。实际上任何可以从命令行调用的工具都可以在自动构建中运行，但值得一提的是一些VisualStudio功能，如代码分析，TFS 2010/VS 2010现不支持。

从更广泛的角度来说，这个系列希望表明的是可持续性集成在SharePoint开发工程中可以有很大的收益。可以更快的发现bugs，通过自动执行的代码质量相关的日常任务还可以提高生产率。