首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

在做TDD时,我为什么要"足够"才能通过测试?

在做TDD(测试驱动开发)时,"足够"是指测试用例覆盖到了足够的代码逻辑,以确保代码的正确性和可靠性。以下是为什么要"足够"才能通过测试的原因:

  1. 确保代码的正确性:通过编写足够的测试用例,可以验证代码在各种情况下的行为是否符合预期。这有助于发现潜在的错误和逻辑问题,确保代码的正确性。
  2. 提高代码质量:通过TDD的方式,开发人员在编写代码之前就需要先编写测试用例。这种先测试后编码的方式可以促使开发人员更加关注代码的质量和可维护性,从而提高代码的质量。
  3. 支持重构和修改:当代码需要进行重构或修改时,足够的测试用例可以提供保障,确保修改后的代码仍然符合预期行为。如果没有足够的测试用例,修改代码可能会导致潜在的错误和功能失效。
  4. 促进团队合作:通过TDD,团队成员可以共享和理解测试用例,从而更好地理解代码的行为和预期结果。这有助于促进团队合作和沟通,减少代码集成时的问题和冲突。
  5. 提高开发效率:虽然编写足够的测试用例可能需要一些额外的时间和精力,但它可以帮助开发人员更早地发现和解决问题,减少后期调试和修复的时间。这样可以提高开发效率,并且在长期来看,可以节省更多的时间和资源。

总之,通过编写足够的测试用例,可以确保代码的正确性、提高代码质量、支持重构和修改、促进团队合作,以及提高开发效率。这是为什么在做TDD时要"足够"才能通过测试的原因。

页面内容是否对你有帮助?
有帮助
没帮助

相关·内容

让我们再聊聊TDD 续——人人都在做TDD|洞见

在上一篇文章里面,通过对DHH的文章以及DHH和Kent Beck等讨论的分析,阐述了对TDD的理解和分类,现在来继续聊聊TDD的实施和分层。...然后通过思考和设计所得到的产出物来驱动代码实现,进而在代码实现中会思考如何通过一个或多个函数或者算法来实现业务逻辑。所以软件系统的实现通过意识层面的思考,再进行技术层面的工作。 ?...如果验证正确,就会认为自己开发的功能正确了,并交给测试人员进行测试。 其实开发人员在开发前思考测试逻辑和用例的过程就是在做TDD了。...只有大量的刻意练习才能让你在真实的代码编写过程中去思考和理解TDD,去运用你通过学习得到的知识,最终才能做到有意识和主动的通过技术去实现TDDTDD的倒三角才能变成一个稳定的砖块,然后哪里需要往哪里搬...既然人人都在做TDD,那么我们为什么不能和黑客帝国里面的Neo一样选择红色药丸来认清楚现实,主动拥抱TDD,并通过大量的刻意练习去改变自己的工作习惯,让TDD成为自己工作习惯的一部分,这样才能更好的提升软件质量

68040

「首席架构师看敏捷数据」核心实践:测试驱动开发(TDD)简介

TDD和传统测试 TDD和文档 测试驱动的数据库开发 通过敏捷模型驱动开发(AMDD)扩展TDD 为什么TDD ? 神话和误解 到底是谁在做这件事? 总结 工具 1. TDD是什么?...套用敏捷建模(Agile Modeling, AM)的说法,您应该“有目的地进行测试”,并且知道您为什么进行测试,以及需要测试到什么级别。...如果不值得测试为什么浪费时间在上面呢? 3.TDD和文档 不管喜欢与否,大多数程序员都不阅读系统的书面文档,相反,他们更喜欢使用代码。这没什么不对的。...“当您查看图1中描述的流程,需要注意的是没有一个步骤指定对象编程语言,比如Java或c#,即使这些是通常使用TDD的环境。为什么不能在更改数据库模式之前编写测试?...到底是谁在做这件事? 不幸的是,TDD的采用率没有希望的那么高。图6总结了2010年的结果:您有多敏捷?提供了关于声称敏捷的团队正在遵循哪些验证策略的洞察。

75820
  • Thoughtworks 徐昊:程序员究竟是搞技术的,还是做工程的?

    相反,在项目组做 CRUD ,从技术上看,我们就是在做 CRUD。但与此同时,还需要理解“为什么要做 CRUD”。这就牵扯到应该如何理解业务上下文和业务逻辑等问题。...TDD 之所以能保证长期稳定的输出,是因为需要我们将测试和代码放在一起去写。为什么这么说呢? 估计你听过“测试就是文档”,这句话并不完全对。测试天然不是文档,而只是记录我们实现软件的过程。...简单来说,就是需求分解成功能点,架构和组件之间的关系在功能点映射成功能上下文,并在功能上下文中分解成任务项,任务项再转成测试。然后通过一个或多个测试的失败,直到让测试通过。...那么为什么TDD 是一个工程化的开发过程呢?要知道,架构(组件与组件间的关系)需要在团队间共享。换句话讲,我们可以从中观察一个架构师是不是把工作做好了。 在做咨询时经常会进行类似的尝试。...可以说,在做任何软件开发,理解需求、懂得架构,都是我们开始的前提和出发点。TDD 就是以这种形式告诉我们,必须以一种能被消费、能看得见摸得着的方式向别人展示“真的懂了需求”。

    69720

    TDD和自动化测试

    什么是TDD?TDD 是敏捷开发中的一项核心实践和技术,也是一种设计方法论。TDD的原理是在开发功能代码之前,先编写单元测试用例代码,测试代码确定需要编写什么产品代码。为什么 TDD?...快速反馈有很多人说 TDD 的代码量增加了,所以开发效率降低了。但是,如果没有单元测试,你就要手工测试,你要花很多时间去准备数据,启动应用,跳转界面等,反馈是很慢的。...图片图片TDD 的三原则没有测试之前不要写任何功能代码一次只写一个刚好失败的测试,作为新加功能的描述不写任何多余的产品代码,除⾮它刚好能让失败的测试通过同时TDD也要遵循测试的FIRST原则F(Fast...维护也遵循 TDD 流程,先修改测试代码成需求变更后的样子,让测试失败,再修改产品代码使其通过。这样你就不是在维护测试用例,而是在利用测试用例。为什么测试代码很简单?...当测试代码足够简单,如果一个测试失败了,就有足够信心断定一定是产品代码的问题。什么时候不适合 TDD

    98020

    作为现代开发的基础,为什么 TDD 没有被广泛采用?

    另外,对于为什么进行 TDD,我们也有不同的看法。强 TDD 的支持者们常常声称,这并非一项测试技术,而是一种偶然使用测试的“设计技术”。但我对这一说法感到困惑,原因有二。...这就将其他形式的测试排除在外:集成测试、端到端测试、突变测试、模糊测试、性能测试、基于模型的测试。 要想让单元测试足够充分,就必须替代所有其他形式的测试。...,当我严格遵守 TDD 就是这样做的。...有了更多的测试,它就会趋于正确,但由于我们将代码封装在一组小型的测试中,因此设计将会变得很不可靠。 既然在做的是“弱 TDD”,所以我还是会在快速排序(QuickSort)之前写一个测试。...如果使用合适的 TDD 所花的时间太长了,那么你能在 Shell 脚本和调试实践中学到一些东西吗?人们什么时候才能停下来? 结    语 甚至不知道的结局是什么。

    51030

    TDD 的原理和使用场景

    这么做可以给我带来非常大的信心,让通过测试后马上知道是什么原因导致的这个 Bug,这样一来,就知道实际上已经修复了这个错误,而不仅仅是围绕这个问题进行了测试。...在维护比较关注的软件,90% 的时间都遵循这种方法(并因此添加了测试)。特别是在的开源项目中就这么做的。这是这类测试的一个例子。 修 Bug 么?试试 TDD 吧。...纯函数场景 不会测所有的工具纯函数(对大部分纯函数我会用集成测试来覆盖),不过,如果某个工具函数有足够的复杂度,而且必须要用隔离的单测来测,那这也是一个使用 TDD 的绝佳机会。...另一个很好的例子就是 的项目 rtl-css-js 的测试(这也是开源的)。 准备写纯工具函数么?试试 TDD 吧。...敢肯定,其他人在做 TDD 实践也有他们自己觉得合理的场景,这也挺好的。 如果只是写点试验代码片段(经常这么干)或者只是乱写写代码,那我肯定不会用 TDD 的。

    39930

    TDD测试驱动开发的实践心得

    很可惜的是,刚开始做Android,属于初次入门做移动端,还没有这种实施TDD的心态,而后又负责iOS,但是接手一个现成的代码,并不是从头开始,所以也压根没有想过实施TDD。...而2020在做基于TypeScript与React桌面端的开发,虽然成功把一个领域驱动思想的风格应用到这个项目中,但没有实施TDD,虽然知道前端有jest这个测试框架,但考虑到时间及因为第一次尝试使用前端技术栈...当然,这篇文章并不是详细阐述TDD的,所以这个点到此为止,笔者后续会就TDD再来专门阐述为什么TDD会加快代码开发。...那在这其中,单元测试的作用很明显,它是程序员自己验证自己代码的一种方式,它需要区分开来其它几种测试保持足够小而且快。...虽然它的很多规则是死的,并不灵活,但至少也能在一定程度上检测自己的代码,特别是在单元测试上提醒自己是否做的足够。 所以,如果你应用TDD,一定需要这样的工具。

    71610

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

    后面我会讲到一些解决的办法,不过在最开始需要强调单元测试的根本性质,这样你才不会误以为剩下的内容讲的是集成测试或者验收测试什么的。   再强调一次:单元测试的根本性质就是正确隔离待测代码。...才能做出断言,特别是当这些前置条件依赖系统的其他组件才能产生的情况下就更要小心!...即使该方法(比如说 a_dog.is_full)的返回结果的确依赖前置条件才能正确输出,单元测试本身也 不应该浪费精力在塑造这些前置条件上,而是应该把重点放在 测试和保障该方法的返回结果是预期的并且在可预见的各种边缘条件下该方法的返回结果都不会超出预期...另外,边界条件的意义就在于不需要穷举所有条件,只要能覆盖就足够),对应的结果应该是什么就可以写出足够测试用例了。...当你拆分一个单元(比如一个方法),你得先确保有足够的单元测试来覆盖原来的代码逻辑,然后把复杂逻辑逐层拆分,每次拆分(往往会多出一个方法来)都应该先有测试用例来驱动分出来的代码,并且在测试的时候除了运行新的测试

    56010

    TDD in .NET Core - 简介

    如果缺陷密度可以降低到足够的程度,那么我们每天都可以交付出具有新功能的软件,这就会与客户建立新的业务关系。 这些概念都很简单,但是动机是什么?为什么开发人员要去写自动测试代码?...为什么开发人员在他们的思维能够大幅飙升的设计时,却只进行小步工作? 勇气。 勇气 TDD是编程过程中管理恐惧的一种办法。...这个恐惧不是坏事,它是一种合理的恐惧,例如:”这个问题确实很难,从开始的感觉看不到尽头“。 如果疼痛是喊停的自然表达,那么恐惧就是告诉你“小心”。...为什么TDD 从业务角度: 提供了需求的确认。通过编写测试以及RGR周期,需求确认很自然的在软件开发的过程中就完成了。 捕获回归问题。回归问题就是指随着软件新功能的发布,以前的某些功能却不好用了。...您可能不喜欢这样,但是现在的目标不是做出完美的解决方案,目标就是让这个测试通过,所以这时候代码可能很烂: ? 写死了数字10。 然后再跑测试: ? 测试Pass了!!

    45910

    《硝烟中的Scrum和XP》第13章 我们怎样结合使用Scrum和XP

    鼓励他们,提供合适的工具,让他们按照自己的节奏去尝试 ---- 测试驱动开发(TDD测试驱动开发意味着你先写一个自动测试,然后编写恰好够用的代码,让它通过这个测试,接着对代码进行重构,主要是提高它的可读性和消除重复...整理一下,然后继续 人们对测试驱动开发有着各种看法 TDD很难:开发人员需要花上一定时间才能掌握。...TDD对系统设计的正面影响特别大 在新产品中,需要过上一段时间,TDD才能开始应用并有效运行,尤其是黑盒集成测试。...但是回报来得非常快 投入足够的时间,来保证大家可以很容易地编写测试。...这意味着要有合适的工具、有经验的人、提供合适的工具类或基类,等等 在新代码上进行TDD 我们在所有 的全新开发过程中都使用TDD,即便这会在开始延长项目配置时间 在旧代码上进行TDD TDD是很难,但是在一开始没有用

    88410

    一个非教条式的TDD例子

    正当我准备写下一个测试运行了之前的所有测试,发现第2个测试挂了 —— 破坏了原来的功能。...之前公司有Senior的同事就和我恨恨地讨论过这点,说实话没有什么理由去反驳这个观点,但我没想明白的是为什么新增一个测试如果直接通过了就不是TDD了呢。测试直接通过了不是更好嘛?...当然前提是你的测试是对的。 后来观察了很多初学者在练习TDD的做法,搞明白这种想法背后的担心。看有人写了第一个测试,然后花很多时间去写实现,结果一股脑实现了很多场景的功能。...所以,为了在学习TDD更好自控,就有了这样的一个教条 —— 新增的测试一定得是挂的。...有时候明明写一个功能完整的代码比简单、丑陋的代码更快,就不会再去hard code,然后假装庆祝自己是在做“真”TDD

    33530

    Vue 应用单元测试的策略与实践 01 - 前言和目标

    [^322](https://github.com/JimmyLv/jimmylv.github.io/issues/322) 为什么 TDD?但是我会讲为什么 UT 单元测试。...测试TDD 是两码事,而光是自动化测试的好处就已经足够多,但是如何做到更好的自动化和持续集成,那就需要 TDD 来指引方向。...单元测试的上下文 谈任何东西都一定要有个上下文。你的论述不能是「因为单元测试有这些好处,所以我们要做单元测试」,而应该是「不做单元测试我们会遇到什么问题」,这样才能回答「为什么要写单元测试」的问题。...那么在这个上下文中来谈要不要单元测试,我们就可以很有根据了,而不是“开发爽了就用,不爽就不用”这样含糊的答案: 如果你说的业务部门不需要频繁上线,并且足够的人力来覆盖手工测试,那你可以不用单元测试...唯解决了人工、质量的这一环,开发效率才能稳步提升,团队和企业的高响应力才可能达到。 至此,回答了「为什么我们需要写单元测试」的问题。

    88840

    笨办法学 Python · 续 练习 27:`tr`

    在实现tr命令,您将再次使用 TDD 进行练习。十分确定,你是先严格编写测试,然后是代码,然后再审计两个东西。 在上一个练习中,让你逐步构建测试用例和代码。...在这个练习中,你会做一些略微不同的事情,因为将会写一个完整的测试用例,进行审计,然后编写整个代码,进行审计,并通过运行测试来确认审计。...同时不要忘记,为此你需要一个整体的项目,它应该是测试完成的 TDD 风格,就像我开始的描述的那样。...这种强烈的专注使编程对来说非常愉快,但是当您对您正在做的事情很感兴趣,它真的是可持续的。当您需要处理别人的糟糕的代码库,这个现象往往不会发生。...尝试阐明为什么,然后阅读一些当前的 TDD 的文章,或它的近亲行为驱动开发(BDD)。 你认为通过首先审计你的代码而不是逐步构建它,你发现了更多还是更少的缺陷?猜测它,然后写下来。

    31010

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

    当我们让开发人员为原有代码编写单元测试,总是觉得举步维艰。分析原因,主要问题在于代码的可测试性不好。测试一个类,竟然连简单创建它的对象都变成了不可能完成的任务。...测试先行的开发至少在一定程度规避了这样的问题。即使代码的内部质量仍有所欠缺,但在足够覆盖率的保护下,我们进行重构也变得更为简单。...测试驱动更像是一种培养设计专注力的手段,就像冥想者通过盘腿静坐的手段来体悟天地一样,测试驱动可以强迫你站在测试的角度(就是使用者的角度)去思考接口,如此才能设计出表现意图的接口。...在TDD过程中,若能结对自然是上佳选择。当一个人在掌控键盘,另一个人就可以重点关注代码的可读性,看看代码是否散发出臭味。两个人的眼睛终归更锐利一些,至少视野的范围更广泛。...当然,只要你的代码能够保证足够的覆盖率,以及较好的松散耦合,重构依旧可行。采用TDD,基本能满足这两条要求。但以成本而论,小步前行才是重构之道。 单元测试的基础设施 最后说说单元测试的基本设施。

    73560

    推行TDD的思考

    在参与的开发项目以及咨询项目中,都有实践TDD的经验。直至今日,仍然会在某些功能开发采用TDD的方式实现功能。...虽然没有达到将TDD溶于开发血液之中形成自然而然的习惯,但至少也是常用的编程利器之一,偶尔使用,效果还算不错。 以下内容则是在某大型团队中推行TDD的一些思考。...当我们让开发人员为原有代码编写单元测试,总是觉得举步维艰,主因就在于代码的可测试性不够好。测试一个类,竟然连简单创建它的对象都变成了不可能完成的任务。...测试先行的开发至少在一定程度规避了这样的问题。因为开发人员首先要写好测试,这就驱使开发人员必须强制地思考代码的可测试性。而在足够多的测试保护下,即使代码的内部质量欠佳,进行重构也更为简单。...测试驱动像是一种培养设计专注力的手段,就像冥想者通过盘腿静坐的手段来体悟天地一样,测试驱动可以强迫你站在测试的角度(就是使用者的角度)去思考接口,如此才能设计出表现意图的接口。

    1.3K90

    单元测试与重构

    事实上,开发人员在交付测试之前都会进行一些基本的测试,确保提交的代码是无误的,尽管你可能不认为这个是在做测试”工作。...比如单元测试,只关注一个单元,开发完成即可进行测试;而集成测试则是要把好几个单元组装再一起进行测试测试通过的前提就是每个单元都正确;系统测试则更复杂,集成好所有模块和单元后,甚至还要维护好基础数据才能进行测试...那么为什么一些开发人员的单元测试写起来这么难?这个问题后面会有答案。 03 测试驱动开发 什么时候写测试?...如果写代码时时刻想着可测性,是为了让测试通过,开发者再写这么长行数的代码都难。了解编写可测试代码的思路,即便不做 TDD,依然对改善软件设计有着至关重要的作用。所以,写代码之前,请先想想怎么测。...当定义的方法明明是getXXX,却改变了入参的属性;当定义方法即有返回值,又改变了入参;当在一个for循环里,改变两个值.....都在违反这一重的原则。

    79740

    TDD测试驱动开发的基础

    在此阶段,测试应该失败,这意味着它可以工作并且不会显示出假阳性结果。 一旦建立了足够测试,开发人员便会继续编写代码。在此阶段,代码可能还不够完善,但必须通过测试才能继续前进。...这就是为什么测试阶段必不可少的原因。 一旦一段代码通过测试,就可以进行重构。这是代码清理阶段,其中删除重复项,正确命名所有代码元素(对象,类,模块,变量,方法等),并添加所有必需的新功能。...然后,测试将进行重构,直到代码通过测试为止;直到代码满足功能为止,然后继续进行测试,并减少系统中的错误数量。 线性过程。(设计代码测试) 循环过程。...(测试代码重构) 测试驱动开发的好处 测试驱动开发的支持者可以在快速开发代码提高其速度,敏捷性和功能。但是,这些并不是唯一的优点。...开发足够的初始测试(尤其是对于创新软件)存在一些问题,因为测试开发人员应该几乎完全知道他们想要从代码中获得什么。 这种方法不允许在初始设计中进行大量更改,否则,这将增加TDD流程的执行时间。

    90610

    「首席架构师看敏捷建模」纪律:敏捷设计理念

    您的单元测试构成了大部分详细的设计文档。使用测试驱动开发(TDD)开发方法,您可以编写测试,然后编写足够的域代码来完成测试。...在需求方面,更喜欢纸和白板等包容性工具,但在设计方面,倾向于使用复杂的工具(重新)为生成代码。就像我的祖父总是说的那样,你应该使用合适的工具来完成工作。 迭代,迭代,迭代。...在记录和文档之间有一个细微的界限,只有通过经验才能找到它。在文档方面尽量保持敏捷。 不要被数据社区所牵制。不幸的是,数据社区中的许多人认为您需要采用串行方法进行设计,尤其是涉及数据库。...如果团队采用测试驱动开发(TDD)方法,则详细设计被有效地指定为开发人员测试,而不是详细模型。因为在编写足够的生产代码来完成测试之前编写测试,实际上在编写测试时会考虑生产代码的设计。...在这种情况下,详细规范和确认测试。 当你停下来思考它,特别是在图2中,TDD有点用词不当。虽然您的开发人员测试正在“推动”代码的设计,但您的敏捷模型正在推动您的整体思考。

    63320

    Vue 应用单元测试的策略与实践 06 - 如何落地的几点建议

    诱饵:从快速见效的事情做起 前文也说过,有些同学就会在心里嘀咕:为了达到“保障质量”的目的,不一定得通过测试呀,就算需要测试,也不一定得通过单元测试。...这话在最开始的时候,确实是对的,谁都想获得好处之后才能放心投入进去,不然那些网络骗子们为什么最开始总会给点回报当作诱饵呢?所以根据测试奖杯?...所以呢,这时候我们明白 Vue 和 Vuex 诞生的背景是什么,理解它们各自解决的问题是什么。只有规范好各自的职责,才能够把 UI 和数据流清晰得隔离开来。...TDD测试驱动开发)的步骤如下,能够时刻给予开发者反馈,从而坚持下去: 没有单元测试,不实现任何功能代码; 只编写仅能代表一种失败情况的测试代码; 只编写恰好能通过单元测试的产品代码。 ?...只能说,这过程并没有想象中的那么容易,质疑、埋怨、叫苦的声音源源不断,但每当只要有一位同学说上一句“好像体会到写测试的好处了”,“这样写,实现代码都变得很清晰了”,哪怕只有一位,那也就足够了。

    89630

    TW洞见 | TDD随想录

    初次接触到TDD通过公司内部的“代码大全培训”,犹如十月革命中阿芙勒尔号的一声炮响,为打开了软件开发的视野。先测试后开发,小步迭代,持续集成,这些新名词突然涌进了的大脑,既新鲜又晦涩。...开发是一项功利性的活动,永远都在追求盈利,而测试就一条红线,一旦跨过就意味着亏损。 小步迭代,“让子弹飞”中有句话很经典:步子一步一步迈,一步迈大了,咔,容易扯着蛋。...TDD讲求的小步迭代是写完一个测试再去写完一个实现,每个实现都是通过测试的,如此累加小胜为大胜,最后所有代码的收尾也不过是让最后一个测试通过而已,就是这样简单。 重构,这是最喜欢的部分,为啥?...而且问题套问题,给他解决浪费半天时间,如果他学会了TDD出的错只在最近一个引入的变化里,就好纠正多了。甚至他自己都能纠正。...博主很是赞同该同事的看法,并且作者认为: TDD重要的不是测试代码本身,是解决问题的思维,也许可以泛化,哪怕没测试,如果能够做到快速验证,反馈,价值的稳定叠加,有足够信心,也未尝不可。

    77770
    领券