Questions tagged «tdd»

Ian Cooper 在他的演讲TDD中，哪里都出错了，将Kent Beck的初衷推到了TDD中的单元测试（测试行为，而不是具体的类方法），并主张避免将测试与实现耦合。 对于行为，例如save X to some data source在具有一组典型的服务和存储库的系统中，我们如何通过存储库对服务级别的某些数据的保存进行单元测试，而又不将测试与实现细节耦合（例如调用特定方法） ）？避免这种耦合实际上不值得付出某种努力/坏处吗？

16 unit-testing  tdd  coupling 

我对TDD相当陌生，在创建任何测试代码之前的第一个测试时遇到了麻烦。在没有任何实现代码框架的情况下，我可以随意编写我的第一个测试，但是它似乎总是被我的Java / OO问题思考方式所困扰。 例如，在我的Github ConwaysGameOfLifeExample中，我编写的第一个测试（rule1_zeroNeighbours）首先创建了一个尚未实现的GameOfLife对象。称为不存在的set方法，不存在的step方法，不存在的get方法，然后使用断言。 随着我编写了更多测试并进行了重构，这些测试也在不断发展，但最初看起来是这样的： @Test public void rule1_zeroNeighbours() { GameOfLife gameOfLife = new GameOfLife(); gameOfLife.set(1, 1, true); gameOfLife.step(); assertEquals(false, gameOfLife.get(1, 1)); } 当我根据在早期阶段决定编写此第一项测试的方式来强制实施设计时，这感觉很奇怪。 以您理解TDD的方式可以吗？我似乎遵循TDD / XP的原则，因为我的测试和实现随着时间的推移随着重构的发展而发展，因此，如果这种最初的设计被证明是无用的，那就可以改变了，但是感觉就像我在向开发者强加一个方向。通过这种方式解决。 人们还如何使用TDD？我可以从没有GameOfLife对象开始，而只有原语和静态方法开始，进行更多的重构迭代，但这似乎太虚构了。

15 java  testing  tdd  extreme-programming 

我在应用程序开发方面只有2年以上的经验。在那两年中，我对发展的态度如下 分析需求 身份核心组件/对象，必需功能，行为，过程及其约束 创建类，它们之间的关系，对象行为和状态的约束 根据要求创建功能，处理行为约束 手动测试应用 如果需求更改修改组件/功能，则手动测试应用程序 最近，我对TDD进行了介绍，并认为这是进行开发的好方法，因为已开发的代码有充分的理由存在，并且可以缓解许多后期部署问题。 但是我的问题是我不能先创建测试，而是要标识组件，并在实际编写组件之前为它们编写测试。我的问题是 我做对了吗？如果不是，我到底要改变什么 有什么方法可以确定您编写的测试是否足够？ 是针对非常简单的功能（相当于1 + 1 = 2）编写测试的好习惯吗？ 更改功能并相应地测试需求是否有所变化是否很好？

15 programming-practices  unit-testing  tdd  acceptance-testing 

我正在重构一个巨大的遗留代码类。重构（我认为）主张： 为遗留类编写测试 摆脱困境 问题：一旦我重构了类，就需要更改步骤1中的测试。例如，以前是旧方法中的东西，现在可能是一个单独的类。一种方法现在可能是几种方法。遗留类的整个景观可能被抹杀为新的东西，因此我在步骤1中编写的测试几乎是无效的。本质上，我将添加步骤3。大量重写我的测试 那么重构之前编写测试的目的是什么？这听起来更像是为自己创造更多工作的学术活动。我现在正在为该方法编写测试，并且正在学习有关如何测试事物以及旧方法如何工作的更多信息。可以通过阅读旧代码本身来学习这一点，但是编写测试几乎就像在摸摸我的鼻子，并且在单独的测试中记录这种临时知识。因此，以这种方式，我几乎别无选择，只能学习代码在做什么。我在这里说的是暂时的，因为我会从代码中重构出乱七八糟的东西，并且我的所有文档和测试在很大程度上都是无效的，除非我的知识会留下来并使我对重构更加新鲜。 这是重构之前编写测试的真正原因-帮助我更好地理解代码吗？还有另一个原因！ 请解释！ 注意： 有一篇文章：没有时间进行完全重构时，为遗留代码编写测试是否有意义？但是它说“重构之前先写测试”，但没有说“为什么”，或者说“写测试”看起来像“很快就会被销毁的繁忙工作”该怎么办。

15 testing  refactoring  tdd  legacy-code 

我想知道资源计划对软件项目的总体影响是什么，项目的需求和设计是由自动验收测试和单元测试驱动的，而不是软件开发的“传统”方法。 根据您的经验，与采用更多“传统”开发方法相比，在TDD下完成软件项目对资源需求的总体影响是什么？在我看来，质量会提高，不确定性会减少，这是因为测试要早完成，但是要求提前进行测试似乎需要更多开发人员时间才能完成。由于预先消除了错误，开发工作量增加了多少，或者实际上减少了多少？ 客户需要多少努力？他们是否必须改变与项目相关的方式，特别是如果它们习惯于预先进行大型设计？客户总体所需的小时数是否增加了，或者实际上减少了？ 我可以想象，在TDD项目开始时（因为没有软件开发计划），在TDD迭代过程中时间估计将非常模糊。例如，是否有20％的项目能使信心增加到足以最终为客户提供或多或少的稳定时间和金钱估算？ 注意：我不是在这里寻找主观意见或理论，所以请不要spec测。我正在寻找更多有关TDD的真实经验。

15 tdd  estimation 

我想问大家，在这种情况下，对以Haskell，scala，ocaml，nemerle，f＃或haXe编写的静态类型的功能代码进行单元测试是有意义的（最后一个是我真正感兴趣的，但是我想利用更大社区的知识）。 我问这是因为，根据我的理解： 单元测试的一方面是使规范具有可运行的形式。但是，当采用声明性样式将规范化规范直接映射到语言语义时，实际上是否有可能以可运行的形式以独立方式表达规范，从而增加价值？ 单元测试最明显的方面是跟踪无法通过静态分析发现的错误。鉴于类型安全的功能代码是一种非常接近静态分析器所理解的代码的好工具，因此您似乎可以将很多安全性转移到静态分析上。但是，无法涵盖代码中使用x而不是y（都为坐标）之类的简单错误。OTOH在编写测试代码时也可能会出现这样的错误，因此我不确定是否值得这样做。 单元测试确实引入了冗余，这意味着当需求改变时，实现它们的代码和涉及该代码的测试都必须被改变。当然，这种开销大约是恒定的，因此可以说，这并不重要。实际上，在像Ruby这样的语言中，它的确无法与优势相提并论，但是鉴于静态类型的函数式编程涵盖了许多基础单元测试的目的，因此感觉这是一个不变的开销，可以不付出任何代价就可以减少它。 由此推断，在这种编程风格中，单元测试已经过时了。当然，这样的主张只会导致宗教战争，所以让我将其归结为一个简单的问题： 当您使用这种编程风格时，您在什么程度上使用单元测试以及为什么使用（为什么希望代码获得什么质量）？或者反过来说：您是否有标准，可以用来限定静态分析器覆盖的静态类型功能代码单元，因此不需要单元测试范围？

15 unit-testing  functional-programming  tdd  haskell  scala 

Code Retreat是一整天的培训活动，着重于软件开发的基础知识。即将到来的是“全球”代码撤退日，我很期待。就是说，我以前去过那里，不得不说有很多混乱……这很好。 我仍然不明白的一件事是，为什么“生命游戏”对TDD来说是个好问题，以及TDD的好坏是什么样子。 意识到这是一个相当开放的问题，请随时发表评论。

15 tdd 

当创建一个像AI这样的系统时，它可以非常迅速地采用许多不同的路径，或者实际上是具有多个不同输入的任何算法，则可能的结果集可能包含大量的排列。 创建一个输出许多很多结果排列的系统时，应该采用哪种方法来使用TDD？

15 testing  algorithms  tdd  artificial-intelligence 

我最近读过一篇文章，其中说到模拟对象经常被误解和滥用。我可以寻找任何清晰的模拟反模式吗？

15 testing  tdd  anti-patterns  object-oriented-design  mocking 

按照目前的情况，这个问题并不适合我们的问答形式。我们希望答案会得到事实，参考或专业知识的支持，但是这个问题可能会引起辩论，争论，民意调查或扩展讨论。如果您认为此问题可以解决并且可以重新提出，请访问帮助中心以获取指导。 6年前关闭。 我想尝试在我们的Web应用程序中实现一些TDD，以减少回归并提高发行质量，但我不相信自动化测试在与Web应用程序一样蓬松的性能上能表现得如何。 我已经阅读并尝试了TDD和单元测试，但是示例都是“可靠的”，并且是诸如货币转换器之类的简单功能。 是否有任何资源可以帮助进行单元测试内容管理和发布系统？如何对购物车/商店（实物和在线产品）进行单元测试？AJAX？ 谷歌搜索“ Web测试驱动开发”只是几年前的老文章，要么涉及类似计算器功能的示例，要么讨论为什么TDD比任何东西都要好（没有任何示例）。

15 web-development  unit-testing  web-applications  tdd 

TDD是关于在测试的指导下设计代码的。 因此，通常不预先构建典型的层。它们应该在重构步骤中稍微出现。 域驱动的设计涉及许多技术模式，它们定义了完善的层，如应用程序层，基础结构层，域层，持久性层。 要从头开始DDD项目的编码部分，应如何操作？ 我是否应该严格让设计从测试中脱颖而出，这意味着没有关注点分离（没有层次）和重构以适合DDD技术模式？ 还是应该创建那些空层（应用程序，实体/域服务，基础结构），并让TDD独立地适合每个层（使用模拟在层之间进行隔离）？

15 architecture  testing  tdd  domain-driven-design 

已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗？更新问题，以便通过编辑此帖子以事实和引用的形式回答。 4年前关闭。 我是团队中唯一使用TDD的人。如何使他们使用它？ 我很烦恼，当我退出时，某人的代码会破坏我的测试，而我是必须修复它们的人。 使用github，fork和pull请求是否可以解决此问题，以便他们需要在接受pull之前通过测试？ 我不是项目经理，我似乎无法说服她使用它。

15 tdd  ruby-on-rails  communication 

我从TDD的实践者那里听到很多东西，TDD的优势之一是它迫使开发人员遵循SOLID原则（单一职责，开放式封闭，Liskov替代，接口隔离和依赖倒置）。但是对我而言，只需编写一些测试（主要是单元测试）就足以理解遵循SOLID（从而创建可测试的体系结构）非常重要。 TDD是否会迫使开发人员更积极地遵循SOLID，而不仅仅是编写单元测试？

15 unit-testing  tdd  solid 

有时候，我会遇到这样的情况：修复错误需要删除一段代码。TDD的纯粹主义者会（我认为）提倡编写一个失败的测试，删除代码，然后查看测试通过。 现在，有一个测试断言某些代码已被删除真是很奇怪。当然，我想它可以确保没有人去研究源代码控制并将该代码放回去，但这值得吗？如果值得的话，它似乎比为已添加的代码编写测试要有价值，对吧？

14 unit-testing  tdd  bug 

当在每次提交时执行测试的持续集成时，通常的最佳实践是使所有测试始终通过（也就是“不破坏构建”）。 我发现一些问题： 例如，不能通过创建与票证相对应的测试来帮助开源项目。我知道如果我向包含失败测试的开源项目提出“拉取请求”，则该构建将被标记为失败，并且该项目将不希望将其合并到其存储库中，因为这会“破坏构建”。 而且我不认为在您的仓库中测试失败是一件坏事，就像在跟踪器中遇到未解决的问题一样。这些只是等待修复的事情。 公司也是如此。如果使用TDD，则无法编写测试，提交并编写满足测试要求的逻辑代码。这意味着，如果我在笔记本电脑上编写了4-5个测试，则在休假前我无法提交它们。没有人可以收回我的工作。我什至不能与同事“共享”他们，例如通过电子邮件发送给他们。这也阻止了一个人编写测试，而另一个人编写模型。 话虽如此，我是否滥用/误解了构建过程/持续集成？在我看来，“通过” /“未通过”是一个过于狭窄的指标。 有没有办法使持续集成和TDD兼容？ 也许有一个标准的解决方案/实践来区分“新测试”（可能失败）和“回归测试”（应该不会失败，因为它们曾经工作过）？

14 tdd  continuous-integration  tests