http://172.17.205.16:8888/FitNesse.UserGuide. DeliveringTheRightSystem

简介：团队怎么来使用FitNesse

       在AcceptanceTests章节里，我们提到了FitNesse是用来构建正确代码的，这个概念是相对于单元测试的作用来说的，因为单元测试保证写出来的代码不是错误的。正确代码，这个说的是正确的系统，就是说我们写出来的东西是具有商业价值的。

每个人都来帮助发表正确的系统

单元测试可以是由单独的程序员或者是成对的程序员来完成，完全可以不涉及到其他的非程序员。FitNesse就必须是用在程序员和非程序员之间。为整个团队成员间讲授FitNesse：管理人士、测试、商业分析人员还有专家、用户代理人、用户、技术写手、支持群体还有其他反正相关人员。每个都可以从定义和运行FitNesse测试中获益。

测试先行

       其实我想大声的呼喊我的测试理想，她不在花丛里，她在哪里？如果她有着Yellow的身型，是否你也会爱上她。让我们这群热爱她的人，大声呼喊！

       项目启动时，不要急着做需求分析，我们可以试着把那些想要系统实现什么的人聚集起来，让他们去定义FitNesse的验收测试内容。如果你在使用敏捷开发，就像是极限编程，你可以把这个步骤安排到你的项目日程表里。这样的实践会带给你的是更多美丽的想法，让你放弃那些陈旧的想法。就像是I’m blind！Please Help！不如换成It’s a beautiful day and I can see it.

把需求和测试表写在一起

       我们不是在要求你放弃你一直拥有的需求处理过程。但我们还是强烈建议把FitNesse测试整合到你的需求处理过程中去。你会发现把需求写在文档里，和使用FitNesse来验证需求是一样easy的。你文档里写的就和测试验证里一样。

示例场景：比如说这有些披萨

       比如说，有家运输公司打算替换他们现有的一个存货控制系统。这是个庞大的系统。所有人都不太能搞清楚它里面的逻辑。在他们打算写文档来理清楚思路的时候，一个关键小姐说FitNesse也许能带来更大的帮助。她要求产品经理去学习下FitNesse，在这个新项目里使用它。他们雇佣一个teacher来做FitNesse的培训，同时用FitNesse来指定一个计划。

       在制定需求前两周，PM找来了很多对系统有需求的人士：一个架构师，一个高级开发，一个测试leader，还有个业务专家，也就是后面会最多使用这个系统的客户。

       PM把这些人给找到一起，定了个小会议室，并放上了一些披萨和饮料。开发就在自己的本本上使用FitNesse写上测试表格！是的！测试表开始工作！真的能运行，当然！人家是高级开发~~

一些测试表

       团队使用披萨，白板，纸，excel，Fitnesse还有活跃的讨论，产出了两个FitNesse测试表。每个表有6到8行，5到6个列。两个表都是关于独立的需求的(简单明了到大家都这么认为)，这些都写在一个测试页面上。这个测试页面上仅有2个表格，还有一些解释性的文字。会议到点后，会在第二天再次召开这样的会议。

“什么，你说的是那个意思”

       测试表格里的描写和文档里写的不太一样，能够运行的需求测试表带给我们的是激动万分。

       当一个团队在文档里写了好多的需求点，他们发现实际上对他们最有用的描述需求的内容是那些输入及输出。

       你会发现在写那些测试表和进行讨论的时候，才真正涉及到需求。多好的事哈！你希望讨论尽可能的早的发生，越早越好，在任何代码code前。

       我们的团队，嘴里塞满了披萨，对需求进行讨论，直到他们完全确定下在测试表格里的内容。大量有价值的需求信息被塞进了可以执行正确的输入和输出里面。

那又怎样？那等带给我们什么？

       我们在这几个小时里得到了什么？我们至少确定了这些内容：

       这两个测试表和它们周围的解释文字描述了最重要的需求里最重要的输入及输出。

       程序员直到了他们的代码是要让这两个测试表通过。

       一旦两个测试表运行为绿色，这个需求就完成了，这样的话，他们就可以转到下个需求点上继续工作了。

       PM，测试和业务专家都确定他们需要在这两个测试表里定义些错误场景，当然这会在下个会议里进行。

“成功的提炼：让我们讨论下这些测试”

       随着时间的流逝，团队在测试页里创建了更多的测试表格和解释性文本。然后组织了测试套件。几周后，测试页和测试用例被分开，重组，移动还有些进行了重新定义。

       在几周的时间里，程序员们把第一个需求里的两个测试表都从红色变成了绿色。他们发出得意的邮件通知。但从PM那得到的不是恭喜的邮件，得到的确实PM说，那些不是人民群众真正想要的。没办法，PM和开发经理聚到一起重新定义那两个测试表格去更准确的描述需求。又过了几个礼拜，程序员再次让测试表运行成功，这次他们得到的是鼓励的邮件。

       这些说明了啥，测试表格对于模糊的需求点更加准确的进行了描述。通过重新定义测试表，以及组织需求的讨论，团队将需求定位的非常准确。(他们也可以重定义他们的系统通过迭代和增量开发，但那是另一个开发的小故事了！)

学习更多

       如果你还没开始做呢，去读读OneMinuteDescription和TwoMinuteExample。或者你也可以去读读AcceptanceTests。