【IT168 技术文档】严格意义上讲，Gated Check-in(门控式签入，呵呵，这是我自己的翻译，英文名很好理解，但翻译起来真难啊!)不应该算是测试的一部分，它是Team Foundation Server(以下简称为TFS)提供的一种代码check in(签入，这是最常见到的对check in的翻译，在本文中还是直接使用其英文，因为这是在平常开发中最常使用的称呼)的方式，即在代码check in之前，先将提交的代码更改与现有代码进行merge，然后对merge后的代码进行Build，如果Build成功则check in，否则就会报错并且不check in所提交的代码。

　　表面上看是与测试没有关系，但实际上它和测试以及产品质量的关系还是蛮大的。因为毕竟代码check in是整个开发过程中发生最为频繁的操作，每次check-in代码的质量直接影响着日常的开发活动。对于绝大多数的开发团队来说，check in代码前不仅要保证编译通过，同时还要最大限度的保证新代码不会破坏已有的功能，也就是要执行测试用例去验证。Gated Check-in中提到的“Build成功”，实际上包含两部分内容：编译成功和测试用例执行成功。

　　启用Gated Check-in功能的方法是很简单的，只需要在Build Defintion的Trigger标签页中选择“Gated Check-in”，例如：我定义了自己的一个Build 叫做“DogfoodBuild”，它的定义如下图所示：

　　在设置了"Gated Check-in"选项后，如果你要进行任何对此Build Definition定义的Workspace包含的代码进行Check in操作(从VS IDE或者在Cmd窗口中使用tf checkin命令)，系统都会弹出下面的对话框，它提示用户当前进行的操作属于Gated Check-in，需要的对所提交的代码更改进行Build验证(validation)，只有验证通过才能将代码更改check in，否则将被退回。

　　选择“Build Changes”按钮，Build验证请求将被提交到TFS服务器端进行验证，验证的内容包括：编译代码和执行自动化测试用例。如果验证成功，则会弹出下面的对话框，提示用户验证成功并且已将代码check in到Source control。

　　其中：

　　View Changeset：通过这个链接可以查看到check in的代码changeset的详细信息;

　　Reconcile Workspace：由于check in是发生在服务器端，你本地的代码变化还没有被同步，通过这个链接来帮助你解决本地代码与刚刚check in最新代码的同步;

　　DogfoodBuild：DogfoodBuild是我所创建和使用的Build Definition，通过这个链接可以查看到本次Build和Check-in操作的详细信息;

　　特别提醒：默认创建的Build Definition定义中只验证了提交代码改变(shelve-set)的是否能够成功编译，并没有执行自动化测试用例。如果要允许自动化测试用例，则需要在Build Definition中将"Fail Build On Test Failure"设置为True，如下图所示。这样测试用例运行的结果，将决定Build的结果。

　　Postscript

　　无意中发现有人为Visual Studio 2008实现了一个类似的于Gated Check-in的工具 - TFS Check-in Validation Tool (http://buddybuild.codeplex.com/)，这位老兄还是蛮有远见和魄力的，很不错，在此赞一个!

　　参考文献

　　http://msdn.microsoft.com/en-us/library/ms181716(VS.100).aspx

　　http://msdn.microsoft.com/en-us/library/dd647547(VS.100).aspx

　　http://msdn.microsoft.com/en-us/library/bb552349(VS.100).aspx