jos*_*arh 6 testing tdd bdd integration-testing
上下文:我正在尝试使用Capybara/Steak进行集成测试,在Ruby on Rails环境中练习BDD,因此这将是我使用的示例,但这个问题是关于BDD最佳实践的一般问题.
假设我有一个(诚然是广泛的)用户故事,如下所示:
Feature:
As an administrator
I should be able to manage my products
我一直在寻找ActiveAdminRails 3 的gem,它允许您使用简单的DSL创建复杂的管理界面.虽然节省时间的潜力巨大,但它也让我很难将这么多功能卸载到第三方代码而不进行测试.
但是,我被告知你通常只需要测试自己编写的代码.因此,按照这种逻辑,我只需要测试它ActiveAdmin是否正确集成,因为这是我实际编写的唯一代码.测试这个的基本方案可能是:
Scenario:
Given I have 20 products
When I visit the product index page
Then I should see 20 products.
这是ActiveAdmin开箱即用的功能.所以我可以进行基本安装并使用ActiveAdmin文档创建Products Admin页面,方案将通过.
当然,我还集成了大量其他方案,例如:
Given I have 20 products
And my products include Apples, Bananas, and Berries
When I sort my products by name
Then Apples, Bananas and Berries should be on the first page in that order.
Given I have 20 products
And my products include Apples, Bananas, and Berries
When I type 'ap' into the Filter by Name field
Then I should see "Apples"
And I should not see "Bananas"
等等
据推测,这些已经过测试ActiveAdmin,因此我不需要再次测试它们,即使它们对我的应用程序至关重要.所以我想我已经完成了,可以转到另一个功能(？).
TL; DR:我的基本问题是,我是否应该为排序和过滤等关键功能编写场景,即使它们已经由外部库提供并且我已经测试了我的应用程序与该库的集成？
BDD和场景的主要优点是它可以让您通过有关场景的对话分享共同的理解.
由于看起来你是团队中唯一的人,你从场景中获得的价值将来自于思考它们,捕捉未来的"你",他们将使用它们来提醒已经开发的东西,并将它们自动化以用作回归测试.
你不具备捕捉,或者如果你认为他们是显而易见的自动化方案.对于使用库的明显功能,应该足以了解该功能,并且只在奇数小边缘情况下编写场景(如果存在).
这是因为BDD的主要焦点不是测试.BDD提供词汇和对话框架,以帮助我们分享理解 - 特别是发现误解 - 使软件更易于更改和维护.我们将自动化作为一个不错的副产品.
如果你想真正测试你的应用程序是如何工作的,你应该继续这样做.如果您没有更改正在测试的位,那么您只需要手动测试一次.
作为一个注释,你会混淆故事和场景模板,这将无济于事.故事通常是通过功能的小切片,这些功能已被分解以更快地获得反馈.
As admin
I want to sort my products
So that I can find things easily by name.
场景是功能行为的一个具体示例,通常使用"Given,When,Then"语法:
Given I have a 120 products
And my products include Apples, Bananas and Berries
When I sort my products by name
Then Apples, Bananas and Berries should be on the first page in that order
And the products should be paginated.
快速回答:然后:不,您不需要为软件库提供的行为编写方案.您可以手动测试它们,然后转到更有趣的东西.