文档建议反馈控制台
首页
学习
活动
专区
工具
TVP
最新优惠活动
文章/答案/技术大牛
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

tdd - 我应该在这里模拟还是使用真正的实现

TDD是测试驱动开发（Test-Driven Development）的缩写，是一种软件开发方法论。在TDD中，开发人员首先编写测试用例，然后编写足够的代码来使测试通过，最后进行重构以提高代码质量。

在回答这个问题之前，我想先解释一下TDD的基本概念和工作流程。

TDD的基本概念：

  • 测试驱动开发是一种敏捷开发方法，强调在编写代码之前编写测试用例。
  • TDD的目标是通过频繁运行测试来提高代码质量和可维护性。
  • TDD的核心原则是"红-绿-重构"，即先编写失败的测试用例（红），然后编写足够的代码使测试通过（绿），最后进行重构以提高代码质量。

TDD的工作流程：

  1. 编写测试用例：根据需求和功能规格书编写测试用例，测试用例应该覆盖各种情况和边界条件。
  2. 运行测试用例：运行测试用例，所有的测试用例都应该失败（红）。
  3. 编写足够的代码：编写足够的代码来使测试用例通过（绿），这可能包括编写新的函数、类或修改现有代码。
  4. 重构代码：在保持测试通过的前提下，对代码进行重构以提高代码质量和可维护性。
  5. 重复上述步骤：重复上述步骤，直到所有的需求都得到满足。

回到问题本身，对于TDD的模拟还是使用真正的实现，这取决于你所处的开发阶段和具体情况。下面我将给出两种情况的建议：

  1. 初期开发阶段： 在初期开发阶段，可以考虑使用模拟来进行TDD。模拟可以帮助你快速验证设计和功能，减少对外部依赖的影响。你可以使用各种模拟工具和框架，如Mockito、Sinon.js等，来模拟外部依赖的行为和返回值。这样可以更好地控制测试环境，提高测试的可重复性和可靠性。
  2. 后期开发阶段： 在后期开发阶段，建议使用真正的实现来进行TDD。这样可以更好地验证系统的整体功能和性能，并且可以更准确地检测潜在的问题和错误。使用真正的实现可以更好地模拟真实环境，确保系统在实际运行时的稳定性和可靠性。

总结起来，初期开发阶段可以使用模拟来进行TDD，以快速验证设计和功能；后期开发阶段建议使用真正的实现来进行TDD，以更好地验证系统的整体功能和性能。根据具体情况选择合适的方法，以提高代码质量和可维护性。

腾讯云相关产品和产品介绍链接地址：

请注意，以上链接仅供参考，具体的产品选择应根据实际需求和情况进行评估。

相关搜索:实现TryFrom我应该使用&str还是字符串我应该在这里使用平面映射还是键值列表映射在实现单例时，我应该使用let还是var？我应该使用expo的react native，还是应该将其弹出？我的eCommerce网站应该使用JWT还是Sessions？我应该使用Winforms组合框的SelectedItem,SelectedText还是SelectedValue？Swift -这段代码是错误的，还是我应该使用UserDefaults？我应该为我的理论模型使用抽象类还是接口？我应该在我的C#程序中使用属性还是应该使用get/set访问器？我应该为我的文件使用s3存储桶，还是应该只使用我的ec2实例我应该使用HL7 RIM还是使用我自己的数据模型？当测试我的使用JWT身份验证的NancyFX网站时，我应该模拟CurrentUser还是添加Authorize标头？我应该使用user_data还是Ansible配置我的EC2我应该使用类来定义将使用相同参数的函数，还是应该使用全局变量？我应该使用新的Type()还是只使用Type()来调用构造函数我应该使用"全球"还是"自我".对于Python中的类范围变量？MySQL:我应该使用TINYTEXT还是VARCHAR(6)来表示简短的单词我应该在recyclerView中使用recyclerView，还是有更好的方法？我的用户名应该使用UUID还是常规auto_increment？我应该在<Link>中使用onCLick={}函数还是使用它周围的元素
相关搜索:
页面内容是否对你有帮助？
有帮助
没帮助

相关·内容

一个完整的TDD演练案例（四）

逸言 张逸的胡言乱语 说明：本讲义是我在ThoughtWorks作为咨询师时，为客户开展TDD Code Kata而编写。案例为Guess Number，案例需求来自当时的同事王瑜珩。...与第一个任务不同的是，我没有使用字符串来表示猜测结果，这是因为这里的历史猜测数据不仅包含了猜测结果，还包含了当前的测测数据。 现在，应该考虑“显示历史猜测记录”的任务了。...TDD根本就不应该用来驱动界面设计，还是将注意力放到业务逻辑上来吧。抛开界面，这里的逻辑就转换为： 当用户猜测了数字后，应该显示历史猜测记录。...对协作的分析应以被测对象为主。一旦分析清楚，就应该编写测试，通过测试来驱动对象之间的协作方式。在编写的测试中，参与协作的其他对象都可以通过Mock来模拟，不一定要有实现，只需体现它们的接口即可。...InputCommand可以定义为接口，真正的控制台实现交给了ConsoleInputCommand类。

83040

iOS开发——TDD、BDD方法以及Kiwi单元测试框架

TDD和BDD 在GitBook上看过一篇文章，一个不写单元测试的程序员不是一个好的攻城狮。坦白的说，在Objective-C这个领域的里，我见过的会主动写单元测试的程序员还是比较少的。...当然了，在那些大的开源项目里，我还是见到过很多单元测试的应用。 于是也就促使我想总结总结自己现在对单元测试的理解。...测试驱动着整个开发过程：首先，驱动代码的设计和功能的实现；其后，驱动代码的再设计和重构。 上面讲述了TDD和BDD的思想差别，看到这里，你们认为当前的iOS开发适合怎样的测试思想。...内部的所有的其他block运行之后调用一次 beforeEach(aBlock) - 在scope内的每个it之前调用一次，对于context的配置代码应该写在这里 afterEach(aBlock)...因为在真正实现时测试时只需要将x删掉就是it，但是pending语意更明确，因此还是推荐pending Kiwi使用实例 就拿项目中一个真实的场景来说，我在写完一个适配所有iPhone机型的宽高的类之后

1.6K20

    • 作为现代开发的基础，为什么 TDD 没有被广泛采用？

    我认为，真正的极致主义者并不多，尽管我至少遇到过一个。大多数倡导者在某些方面是温和的，但在另一些方面却是偏激的——我当然也不例外！...我只在乎它对数据做了什么。 与此相反，“设计”在 TDD 中是怎样组织代码的。munge 是一个公共的还是私有的方法？我们是否应该把 http 响应处理程序分割成独立的对象？...有时候，大型公共 API 会让模块之间的耦合变得更紧密，这就是为了鼓励重用“实现对象”。如果 TDD 与你的组织相抵触，那么有时 TDD 是错误的。...，我并不是想在这里表现得反常，当我严格遵守 TDD 时，我就是这样做的。...TDD 是一种你与其他方法结合使用的方法。有时你会听从这些方法，他们会给出相互矛盾的建议。有时，TDD 的建议会是正确的，有时会是错误的。有时它会错得离谱，以至于你在那种情况下不应该使用 TDD。

    51030

    【敏捷实践】推行TDD的思考

    而惯常的软件开发思想，总是认为开发人员不适合做测试，因为他们总是站在自己的角度去看待问题，从而可能忽略真正需要测试的用例。...我不是说没有采用TDD，代码质量就一定不高；但我可以说采用了TDD，代码质量至少有了可以改进的基础。 分析需求并进行任务分解的能力 需求分析能力常常是开发人员的短板。...这种改变显然不是一朝一夕可以完成的。以我个人的经验以及我所观察到的情况来看，固然是习惯的力量在作祟，然而主因还是因为对TDD方法的掌握程度以及一些误解导致。 前面已经述及，任务分解应该是TDD的起点。...以下是我对于“TDD是否需要事先设计”的个人观点： Martin Fowler的文章Is Design Dead？其实就是对此问题的正本清源。我个人认为，视场景而定，测试驱动开发仍可进行事先设计。...原则上最好能找到一些开源的测试框架，包括生成测试数据，模拟测试行为等……多数情况下，这些开源框架都已经提供了。因为你遇到的问题，别人可能早已遇见过。

    73560

    测试驱动开发(TDD)及测试框架Mocha.js入门学习

    这就需要借助优秀测试框架的帮助，尤其是支持TDD开发模式的自动化测试框架更为重要，因为我使用的编程是语言是Node.js，那么广泛使用的Mocha.js将成为我的首选。 　　...但对我而言，好用，适合才是更重要，因此我还是会选择TDD为切入点，以后可能会根据实际调整。 2. Test Suite 　　　　由上可知，TDD的接口使用的是suite。...由于TDD和BDD，Mocha提供的接口不同，这里我的例子主要是使用TDD。 　　...在这里，我实现一个简单常见的测试用例，来说明Mocha.js如何使用。 　　首先介绍一下几个重要的接口， suite：定义一组测试用例。...这些接口都是与TDD概念中的接口对应与相关实现，方便组织测试用例。BDD的接口在这里不予赘述，可参考官方文档。

    2.3K70

    Thoughtworks 徐昊：程序员究竟是搞技术的，还是做工程的？

    而这，恰恰是我们行业现在所面临的一个重要问题。我们盲目地以为只要技术水平好了，职业发展就能很好。但实际上真正应该提到的，或者说跟职业发展密切相关的，首先是我们的工程能力。...当实现过程经过加工与整理之后，才能变成真正有效的文档。所以说测试提供了大量技术，比我们在代码中写注释或在文档中写编码设计，更接近实际的实现情况。...另一方面，在写测试的过程中，对于同一类型的任务，实现它的效率不仅可以变得越来越高，而且这个效率还是可以被度量的。比如我之前实现类似的任务时，需要一天的时间。...TDD 的整体工作流程 明确了这些，接下来我们就来进一步探讨 TDD 的工作流程。如下图所示，是我在课程中主要使用的一张图。...TDD 实际上并不是一种编码技术。因为它并不能驱动我们在任务项中把功能都实现出来，它真正驱动的是架构。这正是我们讲的编码架构师，是真正的实干型而非 PPT 型架构师。

    69720

    敏捷开发时代，彻底结束了

    现在他在考虑到底该如何改变，是选择SAFe还是DevOps。卡尔·波普尔曾说：“新的基本原则是，为学会避免犯错误，我们必须从我们的错误中学习。”敏捷本身并不能带来投资回报。...我之前陆陆续续写过一系列DevOps文章，我的看法是选择DevOps。大家可以先从了解DevOps入手，我已经在之前的文章《DevOps生命周期，你想知道的全都在这里了！》中已经详细说明了。...03 自动化测试这是实现真正有效的敏捷的关键因素。我听说它被描述为黄金标准，但并非绝对必要。错。自动化测试是绝对必要的。它能让你永远快速。...人们喜欢说他们做的是测试驱动开发（TDD），但通常他们只是说先写测试再写代码。真正的TDD是自动化的。而有效的TDD是立即完成的。人们常说以后再写测试。这永远不会发生。...事实上，自动化回归套件能帮助你实现持续和无限的速度，正如《敏捷宣言》所设想的那样。试图用手动测试来实现敏捷是失败的秘诀。尽一切努力实现自动化，并不惜一切代价保护它。

    11910

    谈谈践行 TDD 后的感受

    大家好，我是码农小余，今天我们来讨论 TDD。本文纯属个人实践后的感受，若有不确之处，欢迎大佬指导和交流！ 细心的童鞋可能看出在小余前几篇文章中都有在实践 TDD。...在进入正文之前，可以想想下面这个问题： TDD 属于编程技术还是规范（意味着 TDD 是一种重要的敏捷需求和敏捷设计技术）？...有人会因为测试无法捕捉所有的 bug 就不写测试，但却忽略了测试真正的价值是能够捕获大多数的 bug。...测试先行：先写测试能让你的注意力集中在接口设计而非实现。常人思考问题通常都是从“正常路径”出发，即用户使用方式最符合规范的那种场景。但作为合格的程序员‍，我们应该敏感地想象数据为空时会发生什么？...小余作为一个前端开发人员，我的看法 TDD 是一种编程技术，它能让我更聚焦代码质量，需要花费更多的精力使用 SOLID 和设计模式去打磨写过的代码，这是当前 TDD 带给我的收益。

    48120

    推行TDD的思考

    我在参与的开发项目以及咨询项目中，都有实践TDD的经验。直至今日，我仍然会在某些功能开发时采用TDD的方式实现功能。...虽然没有达到将TDD溶于开发血液之中形成自然而然的习惯，但至少也是我常用的编程利器之一，偶尔使用，效果还算不错。 以下内容则是我在某大型团队中推行TDD时的一些思考。...评价一个开发人员的绩效，很重要的一个指标就是被测试人员发现的缺陷数。 惯常的软件开发思想，总是认为开发人员不适合做测试，因为他们总是站在自己的角度去看待问题，从而可能忽略真正需要测试的用例。...这恰恰成为许多人反对TDD的借口，铸造了一块坚硬的用于防守的盾。 然而，以我个人经验以及我所观察到的情况来看，这其中固然有习惯的力量作祟，然而主因还是因为对TDD方法的掌握程度以及一些误解导致。...前面已经述及，任务分解应该是TDD的起点。多数开发者未能形成任务分解的习惯。因此在改变为测试先行的时候，错以为应该一上来就写测试。

    1.3K90

    看大神教你正确理解单元测试，不容错过！

    至于各种前置条件（包括边缘条件），可以伪造（后面会讲）它们而不是去调用真正生成它们的其他代码，只有这样才能保证“隔离性”，才能称的上是单元测试。 　　...在这里我尽量不说关于 TDD 的坏话，而是说它能带来的帮助。 　　刚才提到“驱动”二字才是 TDD 的核心思想，因此若想避免 TDD 可能带来的问题，我们就要利用好 TDD 能够驱动开发的这个特性。...这有点像为大型的复杂架构设计接口，你不去考虑具体实现而是考虑输入输出，我喜欢称之为：思路黑盒化。...不过就 TDD 本身再强调两件事情： 　　1、从第一次测试失败到第一次测试成功，这个过程不应该是一步实现的（除非你的代码实在是太简单了，但这样的话也就没必要非 TDD 不可了）。...二、准备重构即有代码，有可能是改善，也有可能是添加新的功能特性或处理新条件的逻辑，再有就是修复 Bug 等，在这里我都笼统的归为重构。

    56010

    深入探索Python中的单元测试与TDD实践指南

    TDD遵循“红-绿-重构”的循环：首先编写失败的测试（红），然后编写足够的代码使其通过（绿），最后进行重构以改进代码质量。让我们使用TDD来重新实现上面的add函数。...如果测试通过，它会输出一条简短的消息，否则会显示详细的错误信息。无论是使用unittest还是pytest，单元测试和TDD都是提高代码质量和可靠性的重要工具。...使用测试驱动开发（TDD）重新实现函数接下来，让我们使用测试驱动开发（TDD）的方法重新实现我们的add函数。按照TDD的原则，我们首先编写一个失败的测试用例，然后编写足够的代码来使其通过。...使用 TDD 进一步开发功能现在我们已经实现了最基本的加法函数，并且使用了TDD的方法来验证它的正确性。接下来，让我们进一步拓展这个功能，例如增加减法函数，并使用TDD的方式来进行开发。...使用 TDD 完善功能并进行重构现在我们已经实现了加法和减法函数，并使用了TDD的方法来确保它们的正确性。接下来，让我们进一步完善这个小工具，并在过程中进行重构，以提高代码的可读性和可维护性。

    43020

    让我们再聊聊TDD｜洞见

    这些理解主要是建立在片面的理解和实践之上，而在我的认知中，TDD的核心是：先写测试，并使用它帮助开发人员来驱动软件开发。...这个就是现在很多人所谓的TDD、实践的TDD、喜欢的TDD、抱怨的TDD，但是它却只是真正意义上TDD的一部分而已。 ? TDD金字塔 再来看看David 的《TDD is dead....其次他提出应该使用”Long live testing”, 而他并没有说明这种测试应该是在编写代码之前还是之后写，以及会不会用来作为客户对于软件的验收标准。...所以他对TDD的理解还是狭隘的，认为TDD只是UTDD，导致他写了这篇文章来批评TDD。有可能他在现实工作中已经使用了ATDD，也就是TDD。...最后来看看Kent Beck、Martin Fowler、David关于Is TDD Dead?的辩论，我觉得他们所说的都有道理，并且也是合理的。

    1.6K70

    我对单元测试和测试驱动开发的见解

    解决的办法遵循三个点： 一是编写业务代码严格执行单一职责原则； 二是面向接口编程，使用依赖注入； 三是利用工具模拟外部资源。...比如：架构组将操作Redis的库编写成静态类，如果执行测试将会影响Redis数据。令人头疼的是，基本上所有的免费框架都不支持Mock静态类。目前，我采取的方法是使用JustMock的付费功能。...而在TDD中，我们需要面对需求编写测试代码。先写测试代码，我相信很多人都会觉得很困惑，没有逻辑，没有方法，测试代码测试什么？TDD的理念是测试先行。...每个测试都针对系统缺陷，那么，同样的错误不会再次发生 TDD 开发应用程序的系统是开放的、可扩展的、灵活的系统。 以上都是废话，我还没完整体验过真正的TDD开发线上系统。...我目前还是觉得，很艰难能坚持TDD模式开发，很难让你的团队的伙伴都转变思维，从测试代码开始。但不妨碍我们去体会TDD，我们带着测试的思维去写业务代码，时刻都想着，我这样设计会不会很难测试。

    80720

    TDD 强迫你 Program to Interface

    还是接上次的内容，继续测试Dollar class 先在有个新的需求--在使用Times方法之前，必须要做用户的身份验证，有权限的人才可以用这个方法，反之则不行。...首先看一下 如果不用TDD 我们脑中第一反应的功能代码实现，应该会是下面的样子--我们去new 了一个LoginChecker的实例，然后调用CheckPass的方法。        ...等CheckPass写完了，我再写Times方法。你是否有嗅出这两种方式写出来的测试都很像集成测试？！TDD是讲究Isolation（独立，隔离）的。...看看现在的 真正实现代码是什么？其实应该是以下这个样子，因为我们还没有 需求（1）。...，用什么依赖注入，我还能用TDD 来写我的实现吗？

    750100

    AutoDev 1.4 规模化 AI 研发辅助：团队 Prompts、自定义活文档、代码检视

    ）的热情，即 #49 issue 中对于《支持TDD开发模式，根据指定测试生成对应实现》，我们构建了 Team Prompts 的功能。...TDD-Red.vm，根据生成的测试用例，编写第一个失败的测试。 TDD-Green.vm，根据生成的测试，编写、优化对应的实现代码。 TDD-Refactor.vm，重构实现的代码。...请返回对应的方法的代码，使用 ``` 开始你的代码块： Prompt 开头的部分是一个 Markdown 的 YAML FrontMatter，用于做一些简单的配置，在这里的 priority 用于配置菜单中的优先级...如果您在实现的一个对外的 SDK，那么我更建议你采用我们在《开发者体验：探索与重塑》中定义的《文档工程》的方式。...IDE 侧应该如何检视代码 在 IDE 侧，我们更推荐的方式是理解业务场景，结合部分的语法问题进行 review。

    57020

    React全家桶与前端单元测试艺术｜洞见

    为什么不谈TDD？ 首先，TDD肯定是有价值的（价值大小不论）。反对TDD的原因一般比较明显，对于TDD是否带来正收益不确定（动机不足）。 某些项目质量要求很高，预算宽绰，TDD势在必行。...(机械也是极限的一部分，你不应该在使用工具过程中面临太多抉择，而应当专注于将业务翻译成测试)。 为什么谈React全家桶？...（图片来自：http://t.cn/RpwS3AK） 测试Reducer是非常机械的，你不需要问自己“我到底应该测哪些东西”，只需要机械地测试初始state和每个switch case就好了。...我们在这里依然从简，只用stateless component这个子集，虽然在用到生命周期方法的时候需要用一下class，但绝大多数时候应该只用stateless component。...如果用Karma + Chrome真正地渲染测试，你会发现共享一个浏览器实例的测试非常慢，几乎无法watch测试，因此我们的TDD cycle就会变得不那么流畅了。

    1.1K72

    代码测试意味着完全消灭了Bug？

    我最近不得不将一个简单的 Java “表情符号替代品”（:joy:→?）移植到 Go。为了确保兼容性，我查看了它的实现类。...我认为这同样适用于代码。 需要澄清的是，我并不是反对单元测试或 TDD，并且声称我们所有人都应该按照生活中的方式编写代码。我编写单元测试并在有意义的时候实践 TDD。...我的观点是，单元测试和 TDD 不是最后一个问题的解决方案，他们不应该不加区别的使用。这就是为什么我频繁的使用诸如“some”和“often”之类的单词。 测试框架 这让我想到了测试框架的主题。...请注意，我说“正确”：大多数项目并不真正使用 BDD，他们只是使用带有 BDD 语法的库，并将其测试代码插入其中。那是特别的 BDD，或者说是伪 BDD。...结语 编写好的软件真的很难。当前我有一些关于如何实现好的软件的想法，但没有完整的实施方案。我知道“总是添加单元测试”和“总是使用 TDD”不是答案，尽管它们是有用的概念。

    48210

    React 单元测试策略及落地

    让谁来写呢（开发人员还是测试人员）？代码实现那么烂，我根本写不出强壮的测试，怎么办呢？ 回答是，这些单元测试应该由开发者，在开发软件的同时编写对应的单元测试。...它应该是内建的，而不是后补的：也即在编写实现的同时完成单元测试，而不是写完代码再一次性补足。测试先行，这正是TDD的做法。使用TDD开发方法是得到可靠单元测试的唯一途径。...长久以来，大家都认为单测是单测，TDD是TDD，说单测必须要有，但是否使用TDD（测试先行）应该尊重开发者的习惯爱好。...用户推送广告”，不得不在前面先按次序断言许多个不重要的实现 测试没有重点，随便改点什么都会挂测试 正确姿势 针对以上痛点，我们认为真正能够保障质量、重构和开发者体验的 saga 测试应该是这样： 不依赖实现次序...当然，它们多少还是依赖了组件内部的实现细节，比如说 find(TouchableWithoutFeedback)，还是做了“组件内部使用了 TouchableWithoutFeedback 组件”这样的假设

    1.1K20

    TDD与FDD技术对比

    大家好，又见面了，我是你们的朋友全栈君。 　　双工(Duplex)是一种在单一通信信道上实现双向通信的过程，包括两种类型，分别为半双工和全双工。 　　...单一天线通常很难有足够带宽去覆盖FDD使用的全部频率，这也需要更复杂的动态调整电路。 　　FDD系统也可以利用单根电缆来实现。在这种情况下，收发信道分别使用不同的频段。有线电视系统即是如此。...TDD系统中发送的信息，无论是语音、视频还是计算机数据，都是串行的二进制数据。每个时隙的长度可能为1字节，同时可以将多个字节组装在一起成帧。 　　...例如，在将数字语音转换为模拟格式的过程中，没有人会认为这一过程不是全双工。 　　在某些TDD系统中，上行和下行可以分配相等的时隙。...一些TDD系统支持动态带宽分配，其中的时隙数量可以按需分配。 　　TDD的真正优势在于，系统只需使用频谱的一个信道。此外，没有必要浪费频谱资源设置“安全频段”，或采取信道隔离措施。

    57720
    点击加载更多

    扫码

    添加站长 进交流群

    领取专属 10元无门槛券

    手把手带您无忧上云

    扫码加入开发者社群

    相关资讯

    热门标签

    更多标签

    活动推荐

      运营活动

      活动名称
      广告关闭

      腾讯云开发者

      扫码关注腾讯云开发者

      扫码关注腾讯云开发者

      领取腾讯云代金券

      热门产品

      热门推荐

      更多推荐

      Copyright © 2013 - 2024 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有

      深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 深公网安备号 44030502008569

      腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号 | 京公网安备号11010802020287

      领券