Question

我不理解以下代码中TDD FIRST principle是如何被遵守的。

以下是关于FIRST原则的说明：

快速：快速运行（子集）测试（因为您将一直运行它们）

独立：没有测试依赖于其他测试，因此可以按任何顺序运行任何子集

可重复：运行N次，获得相同的结果（以帮助隔离错误并启用自动化）

自检：测试可以自动检测是否通过（无人检查输出）

及时：与被测代码同时编写（使用TDD，先写好！）

测验问题：

莎莉希望她的网站在每个月的第一个星期二有特别的布局。她有以下控制器和测试代码：
# HomeController
 def index
   if Time.now.tuesday?
     render 'special_index'
   else
     render 'index'
   end
 end

 # HomeControllerSpec
 it "should render special template on Tuesdays" do
   get 'index'
   if Time.now.tuesday?
     response.should render_template('special_index')
   else
     response.should render_template('index')
   end
 end
没有遵循什么第一原则？


快速

独立

重复

自检

及时

我不确定没有遵守哪个FIRST原则：

快速：代码似乎很快，因为它的测试并不复杂。
独立：测试并不依赖于其他测试。
可重复：每次测试都会得到相同的结果。 'special_index'如果是星期二，'index'，如果它不是星期二。
自我检查：测试可以自动检测是否已通过。
及时：代码和测试代码同时显示在此处。

我在测验中选择及时，因为测试代码是在控制器代码之后显示的。但我提出的问题是错误的，回想起来，这不是一个好的选择。我不确定在这里没有遵循哪个FIRST原则。

Answer 1

这不是Repeatable因为每天不是周二:)如果你在星期一进行这个测试，你会得到一个结果，如果你在星期二运行，不同的结果。

Answer 2

独立且可重复的

它不是独立于日期然后它可以运行重复但技术上你得到相同的结果，因为你选择

对HomeController进行FIRST概念测试的正确方法是改变评估阶段之前的时间

Answer 3

是的，混淆部分原因是F.I.R.S.T.有关＆＃34; I＆＃34;的原则不够完整或简明。在我参加的课程中，该原则被称为 F.I.I.R.S.T。

第二个＆＃34;我＆＃34;代表＆＃34;隔离＆＃34;。上述测试独立于其他测试，但未在单独的类或项目中分离。

[更新]：

隔离可能意味着：

单元测试将功能从SUT（被测系统）中隔离出来。您甚至可以通过单个功能隔离功能。这划分了单元测试或其亲属组件测试和集成测试之间的界限，当然还有系统测试。
＆＃34;测试隔离失败。开发人员永远不应该对测试或被测试的代码进行逆向工程，以了解出现了什么问题。每个测试类名称和测试方法名称以及断言文本都应该准确说明错误和位置。＆＃34;参考：History of FIRST principle
可以从SUT中隔离单元测试，它在不同的开发人员工件（类，包，开发项目）和/或交付工件（Dll，包，程序集）中进行测试。
单元测试，测试相同的SUT，尤其是它们包含的Asserts，应该在不同的测试函数中相互隔离，但这只是一个建议。理想情况下，每个单元测试只包含一个断言。
单元测试，测试不同的SUT，应该彼此隔离，或者从其他类型的测试中隔离出来，当然还有更多类别或其他提到的工件。

独立可能意味着：

单元测试不应相互依赖（显式独立），除了特殊的＆＃34; setup＆＃34;和＆＃34;拆解＆＃34;功能，但即使这是讨论的主题。
特别是单元测试应该是与顺序无关的（隐式独立性）。结果不应该依赖于之前执行的单元测试。虽然这听起来微不足道，但事实并非如此。有些测试无法避免进行初始化和/或启动运行时。只有一个共享（例如类）变量和SUT可能会有不同的反应，如果之前启动的话。你打电话到操作系统？有些dll会第一次加载吗？您已经有了潜在的依赖关系，至少在操作系统级别上 - 有时只是次要的，有时候不会发现错误。可能需要添加清理代码以达到最佳的测试独立性。
单元测试应尽可能独立于运行时环境，而不依赖于特定的测试环境或设置。这也部分属于＆＃34;可重复＆＃34;。之前无需填写20个用户对话框。无需启动服务器。无需提供数据库。不需要其他组件。不需要网络。要做到这一点，通常使用测试双打（存根，模拟，假货，假人，间谍......）。

（Gerard Meszaros' classic work on: xUnit patterns, here coining the name 'test double' and defining different kinds of）

（Test double zoo quickly explained）

（Follow Martin Fowler 2007, thinking about stubs, mocks, etc. Classic）
虽然单元测试永远不会完全独立于它的SUT，但理想情况下它应该与当前实现尽可能独立，并且只依赖于测试的函数或类的公共接口（SUT））。

结论：在这个解释中，“隔离”这个词是“隔离”。更多地强调物理位置，这在某种程度上通常意味着逻辑独立（例如，级别隔离）。

没有关于可能更多的强调和含义的完整性。

另见这里的评论。

但是（好）单元测试还有更多属性： Roy Osherove在他的书中发现了更多的属性＆＃34;单元测试的艺术＆＃34;我在F.I.I.R.S.T.中找不到。原则（link to his book site），这里引用了我自己的话（和首字母缩略词）：

F 对SUT的控制：单元测试应该完全控制SUT。我认为这与测试和运行时环境（例如使用模拟等）无关。但由于独立性如此暧昧，单独写一封信是有道理的。
A utomated（与可重复和自我检查相关，但不相同）相同）。这个需要测试（跑步者）基础设施。
R 提升：明天的测试应该是相关的。这是最困难的要求之一，取决于＆＃34;学校＆＃34;在TDD期间可能还需要临时单元测试。当测试仅测试合同时，这是很好的，但这可能不足以满足高代码覆盖率要求。
C 一致的结果：有效的结果是＆＃34;足够的＆＃34;独立。一致性是，某些人包含在＆＃34;可重复的＆＃34;中。有重要的重叠，但它们并不相同。
S 精灵解释：在命名，整个测试的结构，特别是断言的语法作为关键线方面，应该清楚测试的是什么，以及什么可以如果测试失败则会出错。与＆＃34;测试有关，隔离故障＆＃34;，见上文。
S 商城，简单或用他的话说：＆＃34;易于实施＆＃34; （再次，相关，但不完全相同）。通常与＆＃34; Fast＆＃34;

考虑到所有这些优点，应该比以前更清楚，编写（好）单元测试几乎都很简单。

TDD FIRST原则

3 个答案: