TDD:它是否妨碍了良好的API设计？ - 腾讯云开发者社区 - 腾讯云

开发者社区

文档建议反馈控制台

文章/答案/技术大牛

发布

10个有关RESTful API良好设计的最佳实践

Web API已经在最近几年变成重要的话题，一个干净的API设计对于后端系统是非常重要的。　　...通常我们为Web API使用RESTful设计，REST概念分离了API结构和逻辑资源，通过Http方法GET, DELETE, POST 和 PUT来操作资源。　　...下面是进行RESTful Web API十个最佳实践，能为你提供一个良好的API设计风格。...消费者一个选择字段的能力，这会降低网络流量，提高API可用性。...offset=5&limit=5>; rel="prev", 8.版本化你的API 使得API版本变得强制性，不要发布无版本的API，使用简单数字，避免小数点如2.5. 一般在Url后面使用?

7625 0

设计一套良好的 HTTP API，你需要注意什么？

REST特别适用于客户端与服务器之间的交互，其设计简洁且层次分明，因此在互联网公司中，我们更倾向于采用REST风格来构建HTTP API。REST并非一项标准，而是一种设计原则和约束的集合。...API 的单一职责设计良好HTTP API的第二个关键点是API的单一职责原则。单一职责原则意味着每个API应该只执行一个独立的功能。。那怎么理解这个 API 单一职责原则呢？...我们要知道，在平常的工作中可能会遇到这样的接口，它调用的接口中包含了相当多的功能实现，然而这些功能并不一定密切相关，如果其中一个功能需求改变了，修改这个功能就有可能破坏其他几个功能。...ShowDoc提供了基本的展示功能，需要手工录入；Swagger提供了自动化生成API文档的功能；而YApi则提供了自定义Mock数据和自动化测试集合的功能。...总结设计一套良好的HTTP API需要注意API风格、单一职责原则、文档管理和版本控制。

3831 0

您找到你想要的搜索结果了吗？

是的

没有找到

看完这篇项目设计规约！你应该就能构建良好的工程结构了

com.taobao.jstorm, com.alibaba.dubbo.register ArtifactID格式: 产品线-模块名语义不重复不遗漏先到中央仓库查证一下 dubbo-client, fastjson-api...Version: 主版本号.次版本号.修订号主版本号: 产品方向更改,或者大规模的API不兼容,或者架构不兼容升级次版本号: 保持相对兼容性,增加主要功能特性,影响范围极小的API不兼容修改修订号...,最低限度不要再增加配置项为了避免应用二方库的依赖冲突问题,二方库发布者应当遵循以下原则: 精简可控原则: 移除一切不必要的API和依赖,只包含Service API, 必要的领域模型对象, Utils...(s) net.ipv4.tcp_fin_timeout = 30 调大服务器所支持的最大文件句柄数(fd, File Descriptor) 主流操作系统的设计是将TCP/UDP连接采用与文件一样的方式去管理...OOM的发生是有概率的,甚至相隔数月才出现一例,出错时的堆内信息对解决问题非常有帮助在线上生产环境 ,JVM的Xms和Xmx设置一样大小的内存容量,避免在GC后调整堆大小带来的压力服务器重定向服务器内部重定向使用

7271 0

这些 API 设计里的坑，你踩了几个？

Gin 选择了性能，牺牲掉了功能。但是这个路由库的功能，对于大部分项目完全够用。...接口设计规则以下只是建议，但是实际开发中，一般得根据实际需要进行调整。 1、API有版本信息我相信你在调用一些开源接口时，会发现，他们的接口一般是以 v1 这种字样开头的。...比如：/v1/xxxx 为什么要这样设计呢？我们在设计开发完 API 之后不可能以后都不迭代了吧。当我们发现我们设计的接口需要修改时，却发现这个接口已经上线，被无数人使用。...limit=10 (取10条) Gin里面的 API 版本管理结合我们的接口设计规则，我们做一下调整。...", c.Param("msg_id")) }) r.Run(":8080") 到这里我们的 Gin 路由设计分享就结束了。

2704 0

Java开发中的测试驱动开发（TDD）JUnit与Mockito的应用指南

编写代码：编写足够的代码使测试通过。重构：在确保测试通过后，进行代码重构，使代码更加简洁和可维护。TDD通常遵循一个循环过程，称为"红绿重构"：红：编写一个测试，运行它，发现它失败。...：设置模拟对象的方法返回值。verify(...)：验证方法是否被调用。3.2 Mockito示例假设我们有一个UserService类，它依赖于UserRepository来从数据库中获取用户数据。...早期发现问题：测试驱动开发使得开发人员能够在编写功能代码之前就发现潜在的错误。增强代码设计：在TDD中，测试是先行的，这迫使开发人员思考代码设计和架构，确保代码符合良好的设计原则。...实战中的TDD：编写有效的测试用例在实际开发中，编写有效的测试用例不仅仅是为了验证代码是否正确，还要确保测试的覆盖率广泛且具有良好的可维护性。以下是一些关于如何编写高质量测试用例的实用建议。...通过先编写测试用例再编写代码的流程，TDD能够帮助开发人员及时发现潜在问题，并通过重构提升代码的设计和结构。TDD不仅注重代码的正确性，还促进了更高效的开发流程和更好的团队协作。

5732 0

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

TDD 不会失败。如果它引起问题，那是因为你做错了。 TDD 和生产力之间的权衡关系到学习曲线。一旦你到达山顶，那就没有什么权衡的事了。如果你还在谈论权衡，那就表明你可能在山上的什么位置。...但是 TDD 是否能确保良好的组织？我并不这么认为。我们知道，TDD 的代码看上去是不同的。在其他方面：依赖注入。这使得代码更容易配置，但代价是使其更加复杂。大量的小函数而不是几个大函数。...现在，这是一个相当弱的论点，因为它同样适用于任何种类的设计压力。极繁主义更具体的问题是，代码组织必须以极少的步骤开发。这导致了路径依赖：代码的最终结果会受到你所采取的路径的强烈影响。...这导致了我对极繁主义的 TDD 最大的不满：它强调局部组织而不是全局组织。如果它能让你不对一个函数进行整体思考，那么它也能让你不对整个组件或组件之间的交互进行整体思考。它能带来更好的设计。...写这篇花了我三天时间，我不知道它是否让我或你们中的任何一个人有了更清晰的认识。我甚至不知道我的理解是否正确，因为我并没有做很多研究，也没有处理过一些细节上的问题。

7193 0

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

直接进行任务去完成这个概念描述的事，那么，我们可能很难理解我们为什么要这么做，也可能做不好。）概念解释单元测试是针对一个工作单元设计的测试。这里的工作单元一般是指对一个方法的一个要求。...TDD 的好处严格根据TDD思维，遵循SOLID原则开发能保证代码质量 TDD 确保了代码与业务需求高度一致性 TDD 鼓励创建更简单、针对性更强的库和API TDD 要落实测试单元，需要鼓励与业务方持续沟通...无用代码实际上维护成本非常高 TDD 提供了内置的回归测试。再次执行测试代码可检查修改一个方法逻辑会不会影响到其它现有功能 TDD 阻止递归错误。...每个测试都针对系统缺陷，那么，同样的错误不会再次发生 TDD 开发应用程序的系统是开放的、可扩展的、灵活的系统。以上都是废话，我还没完整体验过真正的TDD开发线上系统。...我目前还是觉得，很艰难能坚持TDD模式开发，很难让你的团队的伙伴都转变思维，从测试代码开始。但不妨碍我们去体会TDD，我们带着测试的思维去写业务代码，时刻都想着，我这样设计会不会很难测试。

8882 0

TDD 的原理和使用场景

重构部分：再回过头看审视自己的代码，把它重构成高可读性和高维护性的代码（这一步最棒的地方在于之前写的测试用例会告诉你在重构时是否会破坏现有逻辑）。...坦率地说，这跟你用 TDD 的感觉和经验有很大关系。当然，也有一些我经常会用 TDD 的经典场景。修 Bug 场景当在修 Bug 时，我喜欢在修复之前先写一个测试来复现它。...定义良好的交互场景直到我创建了 Testing Library[4] 后，我才认为用户界面的 TDD 在 Web 上确实可行，因为：当你在测代码实现细节时，做 TDD 是没有意义的。...几年前我录的一个视频，里面用 Login 组件展示了这样的方法。这已经是几年前的了，现在应该更容易实现。要准备设计一个定义明确的 UI 么？试试 TDD 吧。总结到这里说差不多了。...文章里主要讲了 3 种使用 TDD 的场景：修 Bug 时，写纯函数时，以及设计 UI 时。

4963 0

简单设计落地三板斧

如果你认同简单设计的价值观，我相信解析简单设计原则对你来说很容易理解并接受，它不像面向对象设计原则（比如：SOLID）那么晦涩难懂，它给你指明了一条明朗可通行的道路。...试想如果我们在编写测试阶段就举步维艰，此时不得不逼着自己去思考如何让API能够利于测试。这个过程主要面临了两方面的挑战：视角切换。从用户视角出发，将脑海中的隐性验收测试落地到代码层面。 API设计。...这些挑战对开发人员的设计思维提出了较高的要求，所以也能理解不少新手在起步阶段颇为痛苦，以至于他们会觉得TDD降低了开发速度，对它的价值产生了怀疑。...回到我们文章的初衷 – 落地简单设计，所以整洁的代码至少是：尽量不重复尽量揭示意图尽量简单的小到变量命名，大到类交互设计，我们应该在意识中不断强化对以上三点的认知，在实践中养成良好的编码习惯。...TDD带我们开了一个头，一旦开始了，在过程中不断地审视自己的代码，并通过重构来让代码变得整洁： [53646uwded.png] 欢迎你以文中提到的案例和网站作为开始，进行大量的刻意练习从而让简单设计的核心价值能够着陆你所开发的软件

7801 0

DDD实战篇：分层架构的代码结构

在良好的领域模型之上，实现这些应用应该是轻松而愉快的。...->resolveapi::Api>(); return api.get(); } ---- 测试实现有了领域模型，大家自然会想着如何去实现业务应用了，而实现应用的过程中一定会考虑到单元测试的设计...测试驱动开发TDD无疑是一种好的实践，如果应用得当，它确实能够实现我们上述的原则，并且能够帮助我们交流业务的需求。比较有意思的是，在基于DDD建立的核心模型之上应用TDD似乎更加顺理成章。...下面的测试用例展现了在核心模型上的TDD过程。...DDD的引入从某种程度上解决了这个顾虑，通过前期的战略和战术建模确定了核心领域架构，这个架构是通过预先综合讨论决策的，考虑了更广阔的业务问题，较之TDD应用的业务需求层面更加宏观。

2.6K4 1

如何用正确的姿势打开 TDD？

有了大的需求分析和设计后，我们可以开始细化每个部分的设计。TDD 在这个阶段才应该现身。现身过早，很容易导致返工，现身过晚。。。都开始写代码了，那还是 TDD 么？...它返回给调用者什么样的结果？是的，写下这个测试例的过程就是接口设计的过程。这是我认为 TDD 帮助最大的地方 —— 在写代码之前先考虑清楚接口。...因此，在开发的各个阶段中，可能需要不断地为你的更加细分的接口设计添加新的测试例。一般而言，TDD 应该涵盖这些层次的接口的测试：「用户」级。对于很多项目来说，用户级的接口是 API。...但是我觉得纠结是否是 unit test 并不重要，重要的是你的 T 是否在反映你的设计，你的接口。纠结于 UT 与否，只会陷入八股文的泥潭。...如果你发现你的模块级接口的 test case 总变，那么你可能需要考虑在初期省却这部分的 test case —— 它标志着你要么设计出了问题，要么有些过度 test 了。

1K10 0

程序员眼中的测试

功能性测试 functionaliy 软件的功能性是第一要务，完成一半功能的成品也要强于完成了全部功能的半成品。软件实现了哪些功能？是否真正完成了这些功能呢？...在单元测试的基础上，将所有函数或程序模块按照设计要求（如根据结构图）组装成为子系统或系统，进行集成测试。通常情况下，集成测试是RD进行的一种检验程序内部各函数或各模块联合起来是否存在问题的一种方式。...WebDriver的Api。...抓包分析：charles Charles 常用的网络抓包工具，通过将自己设置成系统的网络访问代理服务器，使得所有的网络访问请求都通过它来完成，从而实现了网络包的截取和分析，配合 SSL 功能，还可以分析...在执行用例时，会通过行为和步骤定义自动调用步骤定义内的代码运行。同时，提供了良好的断言机制，当执行失败时，可以清晰的看到测试用例的执行步骤，明确失败原因。事情都有两面性，没有银弹。

9834 0

让我们再聊聊TDD｜洞见

其次是帮助开发人员，主要是帮助开发人员理解软件的功能需求和验收条件，帮助其思考和设计代码，从而达到驱动开发的目的，所以TDD是包含两部分：ATDD与UTDD。 ?...比如以软件的行为为验收标准，这个是BDD；如果以特定的实例数据为验收标准，这个是EDD；如果以Web Service API消费者提出API契约来驱动API提供者开发API，这个是CDCD等。...这个就是现在很多人所谓的TDD、实践的TDD、喜欢的TDD、抱怨的TDD，但是它却只是真正意义上TDD的一部分而已。 ? TDD金字塔再来看看David 的《TDD is dead....所以他对TDD的理解还是狭隘的，认为TDD只是UTDD，导致他写了这篇文章来批评TDD。有可能他在现实工作中已经使用了ATDD，也就是TDD。...Kent Beck在金钱和人力资源相对充足、时间相对充裕的情况下追求的是代码质量，大量人员的良好协作与平台稳定。

1.6K7 0

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

一贯以来，我们都在强调测试先行，测试先行……容易产生一种错觉，就是认为TDD必须一开始就写测试，“简单设计”嘛，于是就没有了设计。这让那些习惯于事先设计的开发者更难以接受。...以下是我对于“TDD是否需要事先设计”的个人观点： Martin Fowler的文章Is Design Dead？其实就是对此问题的正本清源。我个人认为，视场景而定，测试驱动开发仍可进行事先设计。...这意味着重构是TDD非常重要的一环，它直接关系到TDD开发出来的代码质量。没有好的重构能力，TDD就会有缺失。若说代码的内部质量是生命的话，重构就是灵魂，缺少了它，代码就没有灵性了。...但尽可能地，我们还是希望运用工具提供的自动重构功能，这既提高了重构效率，也在一定程度下确保了重构的安全。当然，重要的是要找到重构的节奏感，即小步前行，每次重构必运行测试的良好习惯。...在TDD过程中，若能结对自然是上佳选择。当一个人在掌控键盘时，另一个人就可以重点关注代码的可读性，看看代码是否散发出臭味。两个人的眼睛终归要更锐利一些，至少视野的范围更广泛。

8076 0

测试驱动进行开发

而一个新手或菜鸟级的小师傅，却可能不知道拉线，而是直接把砖往上垒，垒了一些之后再看是否笔直，这时候可能会用一根线，量一下砌好的墙是否笔直，如果不直再进行校正，敲敲打打。...相对于传统的结构化开发过程方法，它具有以下优势： 1)TDD根据客户需求编写测试用例，对功能的过程和接口都进行了设计，而且这种从使用者角度对代码进行的设计通常更符合后期开发的需求。...而且TDD明显地缩短了设计决策的反馈循环，使我们几秒或几分钟之内就能获得反馈。...4)TDD提供了持续的回归测试，使我们拥有重构的勇气，因为代码的改动导致系统其他部分产生任何异常，测试都会立刻通知我们。...5)TDD所产生的单元测试代码就是最比较好的开发者文档，它们展示了所有的API该如何使用以及是如何运作的，而且它们与工作代码保持同步，永远是最新的。

8801 0

一个非教条式的TDD例子

新的设计基于我对软件设计浅薄的理解，我认为这个分批逻辑和Repository数据存储逻辑分开会更优雅，支持我的几个主要理由是：数据存储逻辑更加纯粹，它只用关心数据的CRUD。...TDD不太提倡在开始前不做任何设计，恰恰它提倡做一些简单且必要的程序接口设计 —— 非教条主义通过对象建模分析，我设计了两个简单的对象，一个是BatchDivider，另一个是Range，UML如下：...关于测试驱动设计，我觉得一点点提前设计是有必要的，它给了我一个宏观的方向，让我能够顺利地开始。我的个人习惯是，在开始写测试代码前我会做一些简单的纸面设计，做一些简单的对象建模，定义好一些对外的接口。...对于那些很复杂的业务场景，通过简单的几个用例确实没法有效看清抽象模式，浮现不出良好的设计，伪实现和三角法不失为一种好的驱动方式。但有时候，你对设计很清楚，实现很明显，这个时候何不直接上呢？...有了它，我跟团队成员沟通起来也更高效，并且在后续非单线程的工作模式中更容易聚焦重点，更方便我去检查任务进展。

3883 0

我在ThoughtWorks中的敏捷实践

TDD，即测试驱动开发，强调的是测试先行。TDD是一个存在争议的主题，因为在一个连测试的没有的代码库中（多数客户也不关心测试代码，他们通常只想要看得到的功能），它的立身之本就不复存在了。...当然，TDD实践存在一定的门槛，TDD更多地考察一个人的设计能力，所以需要有一定经验的开发人员，而新人往往是很难做到这一点，但这不应该是新人不去尝试TDD的借口。...就我个人的经验而言，TDD编码的时候刚一开始的时候并不是那么顺手（因为TDD更偏重设计），心里会觉得比较耗费时间，最终Story的完成时间相差无几，而TDD除了有效地降低缺陷率，还有以下三个方面的好处。...当我们先写测试的时候，就会考虑到被测试的对象要尽可能被方便的测试，此时我们会尽可能的改良我的的API设计，以便利于测试，这样一来，我们写出的代码更具有可测试性，这样的代码往往具备较高的质量。...共同找出代码的坏味道（命名规范，代码整洁，API内聚性，面向对象设计），及时做出改正，提高代码库的质量，有助于后期扩展和维护。

2.9K3 0

推行TDD的思考

这个层次是一种“递归”的状态，视需求的复杂度可以不停向下拆分。任务分解是TDD的核心，是驱动设计和开发的重要力量，却被很多人忽略了。不能不说是一种误解与遗憾。...这容易产生一种错觉，就是认为TDD必须一开始就写测试，“简单设计”嘛，于是就没有了设计。这让那些习惯于事先设计的开发者更难以接受。那么，TDD是否需要事先设计呢？...所以，在运用TDD时，先不要一巴掌拍死，可以先抱着开放的态度尝试尝试。何况，TDD并非一招鲜，吃遍天，总要有适合它的场景。...这意味着重构是TDD非常重要的一环，它直接关系到TDD开发出来的代码质量。没有好的重构能力，TDD就会有缺失。若说代码的内部质量是生命的话，重构就是灵魂，缺少了它，代码就没有灵性了。...但尽可能地，我们还是希望运用工具提供的自动重构功能，这既提高了重构效率，也在一定程度下确保了重构的安全。当然，重要的是要找到重构的节奏感，即小步前行，每次重构必运行测试的良好习惯。

1.3K9 0

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

，也无法确定过程中是否会产生难以预料的变数等等。　　...TDD 也是测试，所以不用想复杂了，它遵循一样的原理，只不过是在没有代码的前提下先写测试罢了。因此你甚至不需要把代码的整个处理过程理清楚，只需要想好边界条件有哪些（这是目标代码的输入或前置条件。...之后就是运行代码看它失败，接着写代码让它成功，此时你有了可靠的测试用例于是可以立即着手优化或重构代码，直到最终交付。所有的测试都是如此，不是么？...不过就 TDD 本身再强调两件事情：　　1、从第一次测试失败到第一次测试成功，这个过程不应该是一步实现的（除非你的代码实在是太简单了，但这样的话也就没必要非 TDD 不可了）。...，每一步都只需要解决简单的问题，最终解决一个复杂的问题；再比如说有助于你写出设计良好，更加健壮，更加易懂的代码等等。

6111 0

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

测试驱动开发(TDD) (Beck 2003;，是一种渐进的开发方法，它结合了测试优先的开发，即在编写足够的产品代码以完成测试和重构之前编写测试。TDD的主要目标是什么?...我喜欢用这个简单的公式来描述TDD: TDD =重构+ TFD。 TDD彻底改变了传统开发。当您第一次实现一个新特性时，您要问的第一个问题是，现有的设计是否是使您能够实现该功能的最佳设计。...如果没有，则在本地重构它，以更改受新特性影响的设计部分，使您能够尽可能轻松地添加该特性。因此，您将始终提高您的设计质量，从而使它更容易在未来的工作。...开发人员TDD的目标是在JIT的基础上为您的解决方案指定一个详细的、可执行的设计。开发人员TDD通常简单地称为TDD。图2描述了一个UML活动图，展示了ATDD和开发人员TDD是如何结合在一起的。...TDD并没有取代传统的测试，相反，它定义了一种经过验证的方法来确保有效的单元测试。TDD的一个副作用是，生成的测试是用于调用代码的工作示例，从而为代码提供了一个工作规范。

8862 0

点击加载更多

相关资讯

热门标签

活动推荐

运营活动

活动名称

广告关闭