《Cucumber:行为驱动开发指南》——2.6 改变格式器

2.6 改变格式器

每次运行Cucumber的时候都查看输出中特性的全部内容很容易让人分散注意力,让我们切换到progress格式器(formatter)以获得重点更为突出的输出,运行如下命令:

$ cucumber –format progress
你可以看到如下输出:

.ruby: No such file or directory -- calc.rb (LoadError)
F-

(::) failed steps (::)

Command failed! (RuntimeError)
./features/step_definitions/calculator_steps.rb:10:in `/^the calculator is run$/'
features/adding.feature:5:in `When the calculator is run'

Failing Scenarios:
cucumber features/adding.feature:3 # Scenario: Add two numbers

1 scenario (1 failed)
3 steps (1 failed, 1 skipped, 1 passed)
0m0.083s

格式器

Cucumber格式器允许通过不同方式来让测试的输出可视化。有生成HTML报告的格式器,有针对Jenkins之类的持续集成服务器生成JUnit XML的格式器,还有很多其他种类的格式器。

你可以使用cucumber–help查看可以使用的各种格式器,也可以自己试试这些格式器的效果。我们将在第11章进一步解释格式器。
不再打印整个特性,取而代之的是progress格式器在输出中打印了三个字符,每个步骤对应一个字符。第一个字符.表示该步骤通过了;第二个字符F表示该步骤失败了,如我们所知;最后一个字符–表示最后一个步骤被跳过了。Cucumber拥有多种不同的格式器,你可以在运行特性的时候用它们生成不同类型的输出,在阅读本书的过程中你还会学到更多格式器的用法。

以上内容是小小的调剂,现在我们回到工作中来,我们还有一个失败的测试要修复!

时间: 2024-09-09 14:06:45

《Cucumber:行为驱动开发指南》——2.6 改变格式器的相关文章

“Cucumber行为驱动开发指南”能带给我们什么

介绍 或许你已经了解到了软件开发中一个头疼的事,就是如何产生正确的需求和围绕这些需求如何有效地进行软件开发?但又不知如何着手? 或许你已经了解到了一些相关的理论知识来解决这个难题,如:行为驱动开发(BDD),验收测试驱动开发(ATDD),实例化需求(Specification By Example),但却发现很难消化所有的信息? 或许你已经建立了一套相关的自动化测试,但总觉得在为测试而测试,没有解决实际问题,有点脱钩? 或许你已经开始着手建立自动化测试来做保障,但对那么多的工具无从选择? 也或许

《Cucumber:行为驱动开发指南》——第1章 为何使用Cucumber 1.1自动化验收测试

第1章 为何使用Cucumber 软件始于一个想法. 我们假设这是一个优秀的想法--一个能让世界变得更加美好,或者至少能让一些人赚到一些钱的想法.而软件开发人员所面临的挑战就是要落实这个想法,使其能真正产生效益. 最初的想法是完美.漂亮的.如果拥有该想法的人碰巧是一个天才软件开发人员,那事情就非常简单了:他无须向任何人解释就能直接把想法实现成可工作的软件.然而更常见的情况是,拥有最初想法的人并不具备使其想法变为现实所必需的编程技能,因此这个想法必须从他的脑中传递到另外一些人的脑中.也就是说,相关

《Cucumber:行为驱动开发指南》——1.2 行为驱动开发

1.2 行为驱动开发 行为驱动开发(Behaviour-Driven Development,BDD)1建立于测试驱动开发的基础之上,它标准化了那些优秀TDD实践者的良好习惯.优秀的TDD实践者以自外向内的方式开发软件,最初他们会编写一个失败的客户验收测试,该测试从客户的视角描述系统的行为.作为BDD实践者,我们细心编写验收测试,作为所有团队成员都能读懂的实例.我们使用这个编写实例的过程来获取业务人员的反馈,以便在开始实现软件之前,我们就知道自己是否是在编写正确的软件.在此过程中,我们会主动开发

《Cucumber:行为驱动开发指南》——2.8 让测试通过

2.8 让测试通过 既然已经有了可靠的失败场景,那就是时候让这个Cucumber场景指导我们编写解决方案了. 有一个非常简单的方案能让测试通过,但该方案其实不会有实际的帮助,不管怎样我们先试一下,哪怕为了好玩儿: 下载first_taste/08/calc.rb print "4" 试试运行cucumber,你会看到场景最终通过了: ... 1 scenario (1 passed) 3 steps (3 passed) 0m0.025s 很好!不过这个方案有什么问题呢?毕竟我们说过希

《Cucumber:行为驱动开发指南》——6.3 照管好你的测试

6.3 照管好你的测试 自动化特性的好处在于你可以把它们作为活文档来长期信赖,因为你会将每一个场景都用于检查产品代码,以确保它们仍然有效.对于同代码打交道的程序员来说,这还有另一件好处:在他们开发系统的时候,那些测试可以充当安全网,对任何破坏已有行为的错误都给出警告. 因此,你的特性可以充当一种反馈机制,对整个团队来说提供关于系统行为的反馈,对程序员来说还能提供是否破坏已有行为的反馈.想让这些反馈循环带来好处,测试需要执行迅速,还需要可靠.我们首先来看看影响测试可靠性的问题.6.3.1 渗露的场

《Cucumber:行为驱动开发指南》——2.9 我们学到了什么

2.9 我们学到了什么 在本章中我们快速浏览了许多不同的内容,所有这些内容都会在后面再次详细介绍,现在来做一个简单的小结并强调几个最重要的地方. 2.9.1 目录结构Cucumber希望你用约定的目录结构来存储特性和步骤定义: features/ adding.feature - step_definitions/ calculator_steps.rb - 如果你真的需要,也可以传递参数给Cucumber,从而改变默认结构,优先使用自己指定的目录结构,但这种按约定存储文件的方法是最简单的. 2

《Cucumber:行为驱动开发指南》——2.5 运行程序

2.5 运行程序 接下来我们实现下一个步骤,编辑 features/step_definitions/calculator_ steps.rb,修改第二个步骤定义如下: 下载first_taste/04/features/step_definitions/calculator_steps.rb When /^the calculator is run$/ do
 @output = `ruby calc.rb #{@input}` raise('Command failed!') unless

《Cucumber:行为驱动开发指南》——第6章 Cucumber常见问题及解决之道 6.1感受痛苦

第6章 Cucumber常见问题及解决之道 如果团队是第一次用Cucumber,用不了多久你就会注意到自己写的代码bug比以前少了.你发现自己可以勇敢地重构那些以前碰都不敢碰的代码.看到自己的第一个场景通过时的那种喜悦,鼓舞着你不断添加一项又一项特性. 然而,一段时间后,事情开始变味了.突然间你发现测试运行的时间实在太长:或者你开始注意到有几个场景会随机地失败,而且通常是在紧张的工期已经临近的时候:也可能不懂技术的利益相关人对这种开发过程兴趣渐失,只剩下开发人员还在阅读那些特性.人们甚至开始问这

《Cucumber:行为驱动开发指南》——6.2 同心协力

6.2 同心协力 6.2.1 偶然细节考虑下面这个为在线邮件客户端编写的场景: Scenario: Check inbox Given a User "Dave" with password "password" And a User "Sue" with password "secret" And an email to "Dave" from "Sue" When I sign in