TDD和BDD是否应结合使用? [英] Should TDD and BDD be used in conjunction?
问题描述
我从TDD思维方式转变为BDD.我了解使用BDD的重点是确保满足软件的行为和业务目标.
让我感到困惑的是，如果我开始使用BDD代替TDD，似乎我无法在如此低的水平上进行测试.例如，在编写具有TDD思维方式的测试时，我可能会测试属性是否已附加到作用域:
it('should attach properties to scope', function () {
expect(MainCtrl.items.length).toEqual(1);
});
这样做，另一位开发人员知道对作用域的分配是预期的并且是将来使用所必需的，如果他们删除了分配或更改了默认设置等，则为他们保存了一些调试信息.
此示例未定义行为，因此不能视为BDD.当然，我可以重写测试说明以使其更加注重行为，例如，页面加载时，设置属性供以后使用，以便用户可以这样做……"，但这似乎太抽象了. >
同时使用TDD和BDD是否已完成? BDD是否可用于为项目涉及的所有各方(包括非技术人员)定义行为，以及为开发人员专门定义TDD?
答案很简单，是的.
但是，BDD和TDD之间的区别并不是您所提到的，我想弄清楚确保满足软件的行为和业务目标"的真正含义是:)
BDD在开发阶段之前，之后一直没有发展. BDD不仅仅是语法，而且不仅仅是从单词"test"到单词"should"的更改. BDD实际上是编写涉及端到端业务的软件的范例. 此页面解释:
BDD是第二代，由内而外，基于拉动，多利益相关方，多规模，高度自动化的敏捷方法.它描述了与定义明确的输出进行交互的一个周期，从而交付了有效的，经过测试的重要软件.
BDD从故意发现开始，在这里，一群人聚在一起，使用场景充实故事".这群人通常由以下各学科的1+组成:产品，开发和质量检查-也称为三大伙伴.此练习在开发之前进行，并且非常擅长在甚至开始开发之前就确定缺陷，并且通过共同的理解可以创建更好的规范.
一旦您有了一个具有良好场景的好故事，就可以使用外部测试方法:
这意味着您从接受测试开始(如果可以，请避免使用UI)，并且在将开发推进到系统中时，您在集成和单元级别采用TDD来处理诸如服务和域对象之类的事情.在这里，您可以选择自己喜欢的任何语法，并且上面用应该"使用的语法也很好.
如果您使用的是Javascript，我们创建了一个名为黑猩猩的开源工具，以完成以下过程:从外到内的测试很容易.
最后，建议您查看以下链接:
I am coming from a TDD mindset into BDD. I understand that using BDD is to focus on ensuring the behaviours and business goals of software are being met.
What confuses me is that if I start using BDD in place of TDD, it seems I'm not able to test at such a low-level. For example, when writing a test with a TDD mindset, I might test that properties have been attached to the scope:
it('should attach properties to scope', function () {
expect(MainCtrl.items.length).toEqual(1);
});
In doing this, another developer knows the assignment to scope was expected and required for future use, saving them some debugging should they have removed the assignments or changed defaults etc.
This example doesn't define a behavior so can't be considered BDD. Of course, I could rewrite the test description to make it more behavior orientated, such as, "when the page loads, setup properties for later use so the user can do so and so..." but this seems too abstract.
Is it a done-thing to use both TDD and BDD at the same time? Have BDD available to define the behaviors for all parties involved in the project (including non-technical) and TDD specifically for developers?
Short answer, yes.
However, the distinction between BDD and TDD is not as you've mentioned and I'd like to clear up what "ensuring the behaviours and business goals of software are being met" really means :)
BDD precedes, envelopes and goes beyond the development stage. BDD is far more than a syntax and not just a change from the word "test" to the word "should". BDD is actually a paradigm to writing software that involves the end-to-end business. This page explains that:
BDD is a second-generation, outside–in, pull-based, multiple-stakeholder, multiple-scale, high-automation, agile methodology. It describes a cycle of interactions with well-defined outputs, resulting in the delivery of working, tested software that matters.
BDD starts with deliberate discovery, where a group of people get together and flesh out the details of a story using scenarios. The group of people is typically made up of 1+ of each of the following disciplines: product, development and QA - also referred to as the three amigos. This exercise precedes development and is very good at identifying defects before you even start development and it creates better specifications through a shared understanding.
Once you have a good story with good scenarios, you can drive development using an outside-in testing approach:
This means you start with the acceptance test (avoid the UI if you can), and as you drive development into the system, you employ TDD at the integration and unit levels for things like your services and domain objects. Here you can choose any syntax you like, and what you have used above with "should" is fine.
If you're using Javascript, we created an open source tool called Chimp to make the process of outside-in testing easy.
Finally, I recommend you look at the following links:
这篇关于TDD和BDD是否应结合使用?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
