Questions tagged «bdd»

最近，我一直在阅读一些有关Literate Programming的文章，这让我开始思考...写得井井有条的测试（尤其是BDD风格的规范）在解释代码作用方面比散文效果更好，并且具有以下优点：验证自己的准确性。 我从未见过将测试与其代码内联地编写的测试。这是仅是因为语言在编写到相同的源文件中时不会趋向于将应用程序和测试代码分开（而没有人使之变得容易），还是人们在原则上将测试代码与应用程序代码分开呢？

91 testing  unit-testing  bdd  literate-programming 

这个问题的简短介绍。我现在已经使用TDD，最近使用BDD已经超过一年了。我使用诸如嘲笑之类的技术来更有效地编写测试。最近，我开始了一个个人项目，为自己编写一个小小的资金管理程序。由于我没有遗留代码，因此从TDD开始是一个完美的项目。不幸的是，我没有体验到TDD的喜悦。它甚至破坏了我的乐趣，以至于我放弃了这个项目。 怎么了 好吧，我使用了类似TDD的方法来使测试/需求发展程序的设计。问题在于，超过一半的开发时间用于编写/重构测试。所以最后我不想实现任何其他功能，因为我需要重构并编写许多测试。 在工作中，我有很多遗留代码。在这里，我写了越来越多的集成和验收测试，以及更少的单元测试。这似乎不是一个坏方法，因为大多数错误是通过验收和集成测试检测到的。 我的想法是，最终我可以编写比单元测试更多的集成和验收测试。就像我说的那样，对于检测错误，单元测试并不比集成/验收测试好。单元测试也对设计有益。由于我曾经写过很多文章，所以我的类总是被设计为可测试的。此外，在大多数情况下，让测试/需求指导设计的方法可导致更好的设计。单元测试的最后一个优点是它们更快。我已经写了足够多的集成测试，知道它们可以和单元测试一样快。 在浏览网络后，我发现这里和那里提到的想法非常相似。您如何看待这个想法？ 编辑 在一个例子中回答这个设计很好的例子，但是我需要对下一个需求进行大量重构： 首先，执行某些命令有一些要求。我编写了一个可扩展的命令解析器-从某种命令提示符下解析命令，并在模型上调用正确的命令。结果以视图模型类表示： 这里没有错。所有类都彼此独立，我可以轻松添加新命令，显示新数据。 下一个要求是，每个命令应具有其自己的视图表示形式-命令结果的某种预览。我重新设计了程序，以针对新要求实现更好的设计： 这也很好，因为现在每个命令都有自己的视图模型，因此也有自己的预览。 事实是，命令解析器已更改为使用基于令牌的命令解析，并且剥夺了其执行命令的能力。每个命令都有自己的视图模型，数据视图模型只知道当前的命令视图模型，而不知道必须显示的数据。 我现在想知道的是，新设计是否没有违反任何现有要求。我不必更改任何我的验收测试。我不得不重构或删除几乎每个单元测试，这是一大堆工作。 我想在这里展示的是在开发过程中经常发生的一种常见情况。旧的或新的设计都没有问题，它们只是随需求而自然变化-我的理解是，TDD的优点之一就是设计不断发展。 结论 感谢您的所有答案和讨论。在此讨论的总结中，我想到了一种方法，将在下一个项目中对其进行测试。 首先，我在像往常一样执行任何操作之前编写所有测试。 对于需求，我首先编写一些验收测试，以测试整个程序。然后，我为需要实现需求的组件编写了一些集成测试。如果有一个组件与另一个组件紧密协作以实现此要求，那么我还将编写一些集成测试，其中两个组件都需要一起测试。最后但并非最不重要的一点是，如果我必须编写一个具有高排列的算法或任何其他类（例如，序列化程序），我将为此特定类编写单元测试。所有其他类均未经测试，但未经任何单元测试。 对于错误，可以简化过程。通常，错误是由一个或两个组件引起的。在这种情况下，我将为测试该错误的组件编写一个集成测试。如果它与算法有关，我只会编写一个单元测试。如果不容易检测到发生错误的组件，我将编写验收测试以查找错误-这应该是一个例外。

62 testing  unit-testing  tdd  bdd  integration-tests 

BDD和TDD是什么关系？ 据我了解，BDD在TDD之上增加了两个主要内容：测试命名（确保/应该）和验收测试。在BDD开发期间，我应该遵循TDD吗？如果是，我的TDD单元测试是否应使用相同的sure / should样式命名？

30 tdd  bdd 

在繁重的jquery / backbonejs Web应用程序中期望100％的代码覆盖率是否可行？当实际代码覆盖率在javascript / jquery中徘徊在92％-95％左右时，由于未达到100％覆盖率而导致冲刺失败是否合理？

28 code-quality  tdd  bdd 

此问题是从Stack Overflow 迁移而来的，因为可以在Software Engineering Stack Exchange上回答。 迁移 8年前。 要开始我不认为这是一个重复的其他问题上的单元测试。我正在寻求帮助的是将其价值表达给程序员，分析师，经理和测试人员团队。通过自动化测试，我认为不需要区分单元测试（例如JUnit），BDD（例如JBehave，Fitness）和UI（Selenium，W​​atir），因为我认为它们都提供相似的价值（但您可以随意写一个不同意的答案:)） 以下是我已确定的列表，正在寻找有助于扩展或完善的答案： 节省时间/成本：编写自动化测试比编写测试案例要花费更多时间。但是，考虑到测试要运行多次，执行自动化测试的边际工作（即成本/时间）要少几个数量级。自动化测试运行便宜，这有助于随着时间的推移更改系统。 文档：没有比测试更真实的方法知道系统如何工作了。其他任何文档通常在撰写时就已过时，但是测试（至少是通过的测试）揭示了事情的实际运行方式。最终用户和API文档均是如此。 代码质量：测试写作迫使您： 考虑客户，因为测试是客户 打破使代码可测试的依赖关系，这通常意味着弄清楚如何使代码不需要其他大型系统可用

25 unit-testing  selenium  tdd  bdd 

行为驱动的开发及其标志性的“ Given-When-Then”场景语法最近被大肆宣传，因为它有可能用作软件功能评估的边界对象。 我绝对同意，Gherkin或您喜欢的任何功能定义脚本都是商业可读的 DSL，并且已经提供了这样的价值。 但是，我不同意它是非程序员可写的（就像Martin Fowler一样）。 有人对非程序员编写的场景，然后由开发人员提供的场景有说明吗？ 如果确实对缺乏可写性达成了共识，那么您是否会看到一种工具的问题，该工具可以从实际测试中生成业务可读的场景，而不是从场景开始并对其进行检测。 更新：关于“场景生成器”工具，它当然不会神奇地猜测业务语言;）但是，就像我们当前使用正则表达式匹配器以自顶向下的方法（在抽象维度上）创建测试一样，我们可以使用字符串构建器以自下而上的方式创建方案。 “仅给出想法”示例： Given I am on page ${test.currentPage.name} And I click on element ${test.currentAction.element} …

24 documentation  bdd  documentation-generation  business-rules 

因此，您已经多次从不真正了解测试价值的人那里听到过。刚开始时，我是敏捷和测试的追随者... 我最近在讨论有关在产品重写上执行TDD的问题，其中当前团队不进行任何级别的单元测试，并且可能从未听说过依赖注入技术或测试模式/设计等（我们什至不会继续清理代码）。 现在，我对产品的重写负全部责任，并被告知，以TDD的方式进行尝试，只会使它成为维护的噩梦，并且对于团队维护来说是不可能的。此外，由于它是一个前端应用程序（不是基于Web的），因此添加测试是没有意义的，因为业务驱动力发生了变化（通过更改当然意味着有所改进），这些测试将过时，其他开发人员将来的项目将无法维护它们，并且将成为它们修复等方面的负担。 我可以理解，在目前没有任何测试经验的团队中，TDD听起来并不好，但是在这种情况下，我的观点是我可以向周围的人教我的实践，但更进一步，我知道TDD会让您变得更好软件。即使我要使用TDD来生产软件，并抛弃所有测试以将其交给维护团队，与从一开始就完全不使用TDD相比，这肯定是更好的方法吗？ 我被提到在一个从未听说过的团队的大多数项目中执行TDD时被击落。“接口”的想法和外观奇特的DI构造函数使他们望而却步。 在尝试出售TDD的简短对话中，有人可以帮助我吗？在屈服于公司/团队之前，我通常会有一个简短的辩论窗口。

24 testing  agile  tdd  bdd 

在您阅读的有关BDD（行为驱动开发）的每个网站中，您都可以找到一个非常简单的好例子，向您展示定义需求的显而易见和容易。但是，尝试在大型产品（而不是计算器示例）中实施此过程，向我展示了事情可能变得（或将变得）非常复杂且难以理解。特别是在稍后更改请求意味着为此需要进行大量的工作来更正集成测试。 所以我想知道，BDD真的值得吗？它是否解决了其他技术无法解决的问题！

22 development-process  scalability  bdd  integration-tests 

假设我们有一个大型企业级应用程序，而没有任何单元/功能测试。由于非常紧迫的期限，因此在开发过程中没有测试驱动的开发过程（我知道我们永远不能在不确定的情况下承诺任何紧迫的期限，但是已经完成了！） 既然所有的截止日期都过去了，事情变得平静了，每个人都同意将我们转变成一个富有成效的基于TDD / BDD的团队...是的！ 现在的问题是关于我们已经拥有的代码：（1）停止大多数开发并从头开始编写所有可能的测试用例还是可以的，尽管一切都可以很好地进行（尽管！）。 ？或（2）最好等待一些不好的事情发生，然后在修复过程中编写新的单元测试，或者（3）甚至忘记以前的代码，而只为新代码编写单元测试，并将所有内容推迟到下一个主要重构中。 有几个好的，如相关的文章这一个。考虑到我们的时间非常有限，还有许多其他项目/作品正在等待我们，我仍然不确定是否值得为此进行投资。 注意：这个问题正在解释/想象开发团队中一个完全尴尬的情况。这与我或我的任何同事无关；这只是一个假想的情况。您可能会认为这种情况永远都不会发生，否则开发经理会造成这种混乱！但是无论如何，已经完成了。如果可能的话，请不要仅仅因为您认为这永远不会发生而投票。

17 unit-testing  testing  tdd  bdd  acceptance-testing 

我试图了解BDD。我读过一些文章，据我了解，BDD是TDD的“下一步”。我之所以这么说是因为我发现两者非常相似，并且正如我在本文中所读到的那样，BDD是TDD的改进。太好了，我真的很喜欢这个主意。 我没有想到一个实用的观点：有一个.feature文件，BA将在其中写入系统将具有的所有预期行为。作为一名学士学位，他不知道系统的构建方式，因此我们将编写如下内容： +方案1：帐户已入帐+ 鉴于该帐户已贷记 而且卡是有效的 而且分配器中有现金 当客户要求现金时 然后确保帐户已借记并确保已分配现金 并确保卡已归还 好的，这很不错，但是系统中的许多部分都可以进行协作，以便可以实现（例如Account obj，Dispenser obj，Customer obj等）。在我看来，这就像一个集成测试。 我想进行单元测试。我如何测试检查分配器是否有钱的代码？还是分配了现金？还是该帐户在需要时借记？ 如何将单元测试与“ BA创建”测试混合？

17 unit-testing  bdd 

在TDD中，有Arrange Act Assert（AAA）语法： [Test] public void Test_ReturnItemForRefund_ReturnsStockOfBlackSweatersAsTwo_WhenOneInStockAndOneIsReturned() { //Arrange ShopStock shopStock = new ShopStock(); Item blackSweater = new Item("ID: 25"); shopStock.AddStock(blackSweater); int expectedResult = 2; Item blackSweaterToReturn = new Item("ID: 25"); //Act shopStock.ReturnItemForRefund(blackSweaterToReturn); int actualResult = shopStock.GetStock("ID: 25"); //Assert Assert.AreEqual(expectedResult, actualResult); } 在BDD中，编写测试使用类似的结构，但语法为“当下（GWT）”： [Given(@"a customer previously bought a black sweater …

13 c#  unit-testing  tdd  bdd 

如果使用BDD进行项目并通过自动验收测试覆盖100％的用户案例，那么测试人员/质量保证人员的角色是什么？ 我想我正在想象开发人员将与产品负责人一起编写验收测试，让我知道这似乎是一个愚蠢的假设。

13 testing  team  qa  bdd  acceptance-testing 

已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗？更新问题，以便通过编辑此帖子以事实和引用的形式回答。 3年前关闭。 我意识到这有点主观，但是我找不到一个合适的案例： 它“应该做某事”它“应该 做某事” 支持风格的支持者提到，它迫使您实际质疑您要实现的目标，而反对者则认为这是多余的。 是否对此达成共识，或者纯粹是风格问题？

12 testing  bdd 

问：将大型公司迁移到Cucumber并在需求数据库中保留至少15年的旧软件需求的最佳方法是什么？ 目前正在考虑： 1）迁移一切 缺点：我们没有无限的时间/预算，我们必须继续前进才能生存，我们无法停止一切，并且GC 100％的遗留要求和遗留测试套件。 2）童子军规则 让一切都比您发现的要好。如果您触摸要求或更改要求，请编写/更新Cucumber功能。缺点：我们将有两个记录系统（黄瓜，遗留要求数据库），可能永远假设给定应用程序的某些角落很长时间都不会被触及。 3）童子军规则加 与＃2相同，但是将未使用单个需求转移到Cucumber的需求放到一个未完成的场景中，并将旧需求复制/粘贴到描述部分。这样，我们（通过未决的方案）就可以得到有关Cucumber如何“发现”我们的度量，并且使我们摆脱了维护旧需求系统的需求。除了在Cucumber中可能是一团糟之外，我找不到其他缺点。 4）在这里插入您的想法。 背景： 一些迁移到Cucumber的项目具有自动化测试套件，而某些项目仅使用过手动测试。它们全部都在旧的需求数据库中维护其需求。我们之所以必须这样做是因为我们的要求是法律/法规和金融工具的复杂逻辑（风险，定价，结构等）的混合。 请记住，这是一家非常大的公司，这使解决方案更加复杂。 我们已经有一些使用Cucumber满足其“新”要求的项目。因此，我们已经试用了该技术，并且到目前为止对我们来说都是可行的。我们混合了Web和纯数据项目。 谢谢 编辑：要回答这些问题...旧版需求管理DB不会将需求连接到测试。这不是“可测试的”。如今，通过在每个项目结束时将需求链接到我们的测试用例管理系统的艰巨且易于出错的手动过程，即可将需求连接到测试。黄瓜对我们来说显然是更好的解决方案。毫无疑问。问题是，如何对具有大量重要要求而又不能因法律和其他原因而丢失的大型组织采取行动。

11 bdd  cucumber 

我有点支持“行为驱动开发”方法论（又名BDD）。我已经使用BDD已有两年了，并且在开发DotNet应用程序时采用StoryQ作为我的首选框架。即使我已经进行了多年的单元测试，并且以前已经转向测试优先的方法，但我发现使用BDD框架会带来更多的价值，因为我的测试抓住了相对而言需求的意图。在我的代码中清除英语，并且因为我的测试可以执行多个断言而无需在测试进行到一半时结束测试-这意味着我可以一目了然地查看哪些特定断言通过/失败，而无需进行调试即可证明。 对于我来说，这确实是冰山一角，因为我还注意到，我能够以更有针对性的方式调试测试和实现代码，从而提高了我的生产力，并且我可以如果由于输出进入构建日志而导致问题一直困扰到集成构建，则可以轻松确定发生故障的位置。此外，StoryQ api具有很好的流利语法，易于学习，并且可以以多种方式应用，不需要外部依赖就可以使用它。 因此，有了所有这些好处，您会认为很容易将概念引入团队其他成员。不幸的是，其他团队成员甚至都不愿看StoryStorQ来对其进行正确评估（更不用说应用BDD的想法了），并说服彼此尝试从我们自己的核心测试框架中删除许多StoryQ元素，甚至尽管他们最初支持使用StoryQ，但是即使他们希望删除的代码也不会影响我们测试系统的任何其他部分。这样做将最终导致整体上显着增加我的工作量，并且确实与实际情况背道而驰，因为我通过实践经验深信，这是在特定的工作环境中以“测试优先”的方式工作的更好方法，只会导致更大的工作量。鉴于以下情况，我们的软件质量得到了改善 我们发现更容易坚持使用BDD进行测试。为了进一步澄清，我们大多数的单元测试往往都很脆弱且难以维护，多年来由于应用程序测试不佳而导致的结果是，由于不愿坚持测试驱动的流程，开发人员退回到了旧习惯，在项目结束时进行所有测试（这些人声称自己是敏捷的！）。 因此，问题实际上归结为以下几点： 我可以使用哪些论点来真正说明这个团队使用StoryQ或至少采用BDD方法会更好？ 您能否指出我能用来支持我的论点以采用BDD作为我们的标准选择方法的任何轶事证据？ 您能想到什么相反的论点，这可能表明我希望鼓励团队采用BDD的想法可能是错误的？是的，只要论据是合理的，我很高兴被证明是错误的。 注意：我并不是在主张我们全面重写测试，而只是为了以后的所有测试工作而以不同的方式开始工作，最好以与客户互动的方式开始。 对于希望进一步了解BDD的人来说，以下链接可能会有用： http://dannorth.net/introducing-bdd/ http://en.wikipedia.org/wiki/Behaviour_driven_development http://behaviour-driven.org/简介 对于那些对更多细节感兴趣的人，我们是一个由4人组成的小型团队，致力于大约5个大型项目。BDD的“试验”最初进行了大约2个月，随后又进行了大约4个月。团队接受了我应该继续以这种方式工作并进行自己的尝试。自试验结束以来，我一直从事BDD工作约两年，而其他人则非常擅长回避问题。我不是在问题上施加“对抗”，而是在寻找一种方法来温和地说服团队摆脱集体的落后，并抽出时间来做好自己的工作。

11 productivity  agile  unit-testing  bdd