对该API的功能有三级理解： API范围-基本上，此API提供什么功能？通常，这只是了解API提供的端点（对于RESTful API）或API公开的查询和突变（对于GraphQL API）的形式。...端点功能 -一旦您确定了API中所有可用的端点的范围，现在是时候了解它们的全部功能和工作方式了。...从表面上看，这就像知道端点将要做什么一样容易，但是理想情况下，在这一步中，您应该开始对这些端点有一个深入的了解-它们期望什么参数？可能值的范围是多少？什么是边缘情况？发生时会发生什么？...最好的方法是仅向每个端点发出请求，以尝试不同的方案和输入，直到您对它的工作原理有了扎实的了解。 用户流-仅了解API的每个部分的作用还不够；还必须了解API如何在应用程序中组合在一起。...良好的API测试平台可让您定义SMS，电子邮件以及其他在测试失败时发出警报的渠道。 10）将测试集成到您的开发周期中 开发测试不应只是一次执行的离散任务，而应是代码库每项改进的一部分。
对于测试，我们看到了两点： 单元测试容易执行失败，因为它们与实现细节联系得太过紧密了。可悲的是，我们通常需要花很多时间来修改测试。我们之前已经提到了这样做的后果。 集成测试抗拒重构。...应用程序级别的集成测试 我们只需要对单元测试没有覆盖到的东西进行集成测试，比如其他框架功能：端点配置、序列化、数据和错误的反序列化、数据访问、远程调用、验证。...在那之后，我们又检查了一遍，找到了一个不一样的方法。我们最终减少了 75% 的代码，实现也更加简单。 遗憾的是，单元测试单独对这些方法进行了测试，而我们有一堆这样的单元测试。...在第二列中列出你正在做或没有做的事情，这些事情会阻碍你实现第一列中提到的目标。 在第三列中列出你为什么要做第二列中的事情的原因或承诺。...我经常会在做其他事情的同时收听播客，但这个博客值得你认真听。 播客以 Brown 提出的一个问题开始：“为什么我们都想要发生转变，但没有人想要做出改变？”
先从我的背景开始讲起吧。我将自己视为“TDD 人”。早在 2012 年我就学会了 TDD，它帮助我获得了第一份软件工作，而我之前的两份工作，都是在 Ruby 中严格执行 TDD。...有些人声称，TDD 对编程的重要性，就像洗手对医学的重要性一样。 为什么会有区别？因为我们指的是两件不同的事情。我实行的是“弱 TDD”，这只是意味着“在代码之前编写测试，在短的反馈周期内”。...还必须替代基于非测试的验证技术：手动测试、代码检查、类型系统、静态分析、合同、把断言语句推得到处都是。 “可是，从来没有人说过，你只需要做一个单元测试！”...但与最大的 TDD 不同，我不会去编写一个单元测试。...听到公司不使用它，就像听到公司说“你听说过这个叫 Linux 的新东西吗？”卧槽。 所以，在所有这些之后，我有了我的假设，即为什么 TDD 没有传播开来。老实说，这是一种相当反常的假设。
我写了很多测试，也读了很多。他们中的大多数帮助我及早发现错误，提供代码文档并帮助回归测试。但我也发现一些单元测试没有做到这一点。...相反，它们要么非常复杂，以至于无法弄清楚它们在测试什么，要么会随机失败，要么根本不会失败。 本文介绍了导致单元测试无效的五个陷阱，以及如何修复它们。 为每个函数编写一个单元测试 看起来很简单。...那么，为什么沉迷于它不是一个好的想法呢？ 代码覆盖率只是一种测量工具。100% 的代码覆盖率并不意味着你已经覆盖了所有的边缘情况，它只是意味着所有的代码路径都被执行了。...我见过模拟 Web 框架 (flask) 一半的测试，只是为了测试为端点注册函数是否有效。这是测试一小部分功能的大量工作。如果你弄错了，那就很明显了。一旦你做对了，它在未来不太可能改变。...如果您的测试或被测代码以不确定的方式运行，您将对测试失去信心。每次失败时，你都会问：我的测试失败了，还是会通过重新运行？重新修改运行都会给你的测试用例带来修改的麻烦，你甚至想要放弃单元测试用例。
目录： 为什么要有测试？ 测试包括哪些类型？ 为什么要有单元测试？ 单元测试的七点特征 Mockito & Assert Junit、TestNG 和 DEVOPS 为什么要有测试？...一般是通过重新执行所有在前期测试阶段建立的测试用例，来确认问题修改的正确性。 为什么要有单元测试？...不能依赖其他的测试或者其他的测试执行顺序，一个单元测试是独立的。 有一百个测试用例，那么这一百个都应该是独立的，其中九十九个成功了，一个失败就只影响它这一个测试用例，不应该有测试依赖。...例如，想做一个上线动作，上线的改动就只是做一些配置文件的变动，这种变动其实是很危险的，应该把 configuration 同样当做源代码来对待，上线之前要做测试公告，要有配置版本管理等。...Mockito & Assert 这里我不打算写这两个工具的具体使用方法，只是介绍，具体使用看看后期要不要安排写一篇。 上面我说单测不能依赖外部资源，但是实际代码里面确实是有这些操作的，那怎么办呢？
或许下面这些问题能让很多质疑用测试菱形替代金字塔的声音： 问题是由单元测试或单元测试编写所引起的吗？ 集成测试是否应用于需要的组件？ 我的误解是否导致了多处相同的断言？...如今的集成测试常常用于同一团队所开发的代码单元，这就意味着每个源码文件都是一个系统边界，相当于每个代码文件都是由同一个自主团队开发一样，模糊了单元测试和集成测试之间的界限。...类似于 Alistair Cockburn 所描述的 六边形架构，后者也被称作是“端口与适配器”。在他的描述中，系统拥有里外两个面，而我们要做的，就是通过明确定义的边界来连接这两个面。 这有什么用呢？...这段定义中完全没有提到过任何针对单一文件、对象，或者函数的测试。那么，为什么编写针对行为的测试很难？...而集成测试由于更多地脱离底层的设计，受重构的影响往往比单元测试要小。 我更倾向于从另一个角度看问题。这一点是集成测试的优势，还是由透明盒测试所带来的问题？
因为没人能保证在修改代码后，不会引发其他额外 bug（功能失效，渲染失败），而在修改完代码后，跑一遍测试就能很大程度让开发者发现自己所修改的代码是否存在问题，是否会导致原有功能失效。...怎么理解这句话呢：比方说我要测试获取博客列表的函数，假设实际的接口失效了，那么就会导致结果与预期不一致，就会导致代码测试不通过。既然不通过，那我就要去查看为什么不通过。...当我点击这个单元测试的时，发现原来是后端接口失效了。可万一哪天这个接口突然好了，又或者发现刚刚原来没插网线导致的请求失败导致测试不通过。...像这些 不稳定因素 在前端自动化测试中就会使用 mock 的方式，强制返回一定格式的数据给测试框架。到这里你可能会好奇，为什么要这么做？ 想想看，如果因为接口失效导致测试失败，是因为测试代码的问题吗？...确保后端返回正确的响应结果，前端能够对这些数据进行处理渲染，这才是我们要做的。 每次测试都存在不可控的因素，就会导致每次测试结果都有可能不同，这就违背测试的意义了。
当然，这只是我选择这篇文章理由之一，另一个理由是，我总感觉，作为文章中所举的例子来说，似乎并非只有回归单体应用这一条路线，比如，我并未在文章中看到诸如API网关的相关描述--文中所讲的消息路由只解决了网关的一部分问题...如果想要部署一个变更，我们还得花时间来修复此前失败的测试，而对这个测试的修复完全与我们要做的变更无关。针对这个问题，我们决定将每个节点的代码放在各自单独的代码库中。...这些结构中包含了基本的单元测试，以验证我们的自定义转换逻辑是正确的，并将对合作伙伴的端点执行HTTP请求，以验证事件是否如预期的那样出现在目标节点中。...构建弹性测试套件 在测试运行期间，对目标端点的出站HTTP请求是测试失败的主要原因。而有一些不相关的问题，如过期的凭据，本不应导致测试的失败。...我记得在集成了流量记录仪之后，我第一次为每个目标运行测试。完成所有140多个目标的测试只花了几毫秒的时间。而在过去，对于一个目标可能就需要几分钟才能完成。这感觉就像做梦一样。 为什么单体架构有效了？
代码将所有内容抽象到开发者难以想象发生了什么的程度，只是为了向原本非常简单的函数中添加“单元测试”。DHH 称这种为测试引起的设计损坏。 测试只是确保用户的程序正常运行的工具之一。...有时你可以做一个简单的实现，而不牺牲任何可测试性；太棒了！但是有时你必须找到一个平衡点。对于某些代码，不添加单元测试是可以的。 对“单元测试”的过分关注可能会对代码库造成难以置信的损害。...有些代码库有大量的单元测试，这使得任何更改都非常耗时，因为你要为哪怕是很小的更改而修复一大堆测试。很多时候，这些测试都是重复的；像简单的 CRUD，HTTP 端点的每一层添加一个测试是一个常见的示例。...所以你需要集成测试，如果集成测试重复了一半的单元测试，那么为什么还要为这些单元测试烦恼呢？ 测试驱动开发（TDD）也只是一种工具。它可以很好的解决一些问题; 对其他人而言并非如此。...我的观点是，单元测试和 TDD 不是最后一个问题的解决方案，他们不应该不加区别的使用。这就是为什么我频繁的使用诸如“some”和“often”之类的单词。 测试框架 这让我想到了测试框架的主题。
但是我不想和博客园一样翻车，因此我需要做一点集成测试的辅助，尽管依然还是翻车了，但是我要学习博客园伟大的精神，将在这个项目里面所做的所有自动化测试项目的方法写下来 在开始从 dotnet core 3.1...然而这个方法一开启我就被拖出去了…… 因为开启主机会占用端口，而刚好我的几个项目都采用了相同的端口 而我开始尝试在配置文件里面指定随机的端口，而此时又有玄学的网络权限，但是我又不知道将谁拖出去 此时小伙伴给我安利了...只是自己的应用不会去监听端口而已 先新建一个项目，这是一个单元测试项目，用来做集成测试 在 dotnet 里面的套路就是先安装 NuGet 包，然后调用。...当然了这是对简单的接口可以这样写，但是对复杂的接口来说，有很多特殊的需求，此时就需要用到 CUnit 库了，通过安装 MSTestEnhancer 这个 NuGet 库就可以添加单元测试辅助库，如下面代码...在经过了两天的更新依然失败之后，我强行魔改了代码，上到了 dotet 5 之后，发现了 APM 挂了…… 因 APM 内部使用了原先 dotnet core 3.1 的在 dotnet 5 废弃的接口…
这么多年来，我们一直都在被 “制式的教育” 着⋯ 单元测试是保证质量的必要的手段，无论如何是一定要做的。 但有人能说得清楚，单元测试到底能保证什么样的质量吗？...许多人都会说，Ken 你问这些问题，就代表着你不懂单元测试⋯ 是的，我是不懂单元测试；我更不懂的是，为何会有开发人员在“完全不明白” 自己苦苦、甚至是熬夜所写出的单元测试用例与产品质量间的关系时，还是愿意傻傻的在那写单元测试用例...这么多年来，我们一直都被 “制式的教育” 着⋯ 自动化、手工集成测试用例一定要做到如何，如何，产品才能发布。...思考着这些测试方法、测试工具其实ㄧ点都不难的；在2014 年，我也只是想着，不要再写笨重、无用的需求文档、设计文档，但又能保证产品的质量与提升开发的效率，所以，就整合了既有的一些工程实践，创建了 Story...所以, 当单元测试、集成测试不可信任时, 我们应该重新的创建、设计 “真正有效”、“真正高效” 的测试方法，测试工具。而我们要问的问题，应该不是：真正高效的测试方法及工具是什么？
否则，或者如果它崩溃，测试将失败。 我需要测试些什么？ 现在我们已经了解了单元测试是如何工作的，下一个问题是我们应该测试什么。...这可能看起来很琐碎，你们中的一些人可能会认为我在测试这个方面很迂腐，但是我不知道我有多少次因为我搞不清楚填充函数是如何工作的而导致了形状错误。...它们测试了增强是如何工作的这一单一的概念，因此应该属于相同的测试函数。但是，通过这个组合，我们引入了另一个问题。如果测试失败了，现在很难直接看到哪一个部分失败了。这个包只告诉我们组合函数的名称。...我们在此所使用的核心原则可以应用到我们在前面几节中编写的所有其他单元测试中。你可以在附带的存储库中看到结果测试。...虽然相对简单，但这种变换可以演示几个值得进行单元测试的方面。 模型的输出形状 我们在本文开头看到的第一段代码是几乎每个人都要做的测试。我们也已经知道这个测试是如何写成单元测试的。
本文所探讨的对象，更多的也是与业务逻辑相关的可测单元。...二、为什么要做单元测试 Kent Beck，在其提出的极限编程（Extreme Programming，简称XP）中就使用单元测试作为质量保障的重要手段，也曾与设计模式四巨头之一ErichGamma 共同开发了...有趣的是，在 stackoverflow 上一则关于《单元测试应该做到多细》的问题探讨上，Kent Beck 的回复却出乎很多人的意料，他并不推崇一定都要做单元测试，而更倾向于只针对于容易出错、没有信心的部分代码做测试...译：老板为我有效的代码支付薪酬，而不是测试，所以我的理念是在能达到的自信水平上做越少的测试越好（我觉得这种自信水平应该要高于行业内的标准，当然这也可能只是我的自大）。...单测意识缺失 那么，为什么开发同学不做单元测试呢？是和上文提及的一样，因为对自己的代码已经有足够的信心么？又或者，是因为并没有做单元测试的自驱力呢？
我们要做 DevOps 的时候，首先要意识到这个的问题。 有的时候你忙忙叨叨，做的很多工作其实都只是你能做的，然而并不见得是你应该做的。...开发人员每天至少提交一次代码 代码提交后立即触发构建和测试 构建和测试失败后应尽快处理 持续集成不是什么新鲜词汇了，每个人都在说持续集成，这是我定义中的持续集成，这三条，清晰的定义了在做到“持续集成”之后...这个太复杂了，我不细说了，我想告诉大家的是自动化部署是克服各种困难都要去做的事情，是应该做的事情。 四. 失败之回顾反思 下面说一点，我们的失败与反思。...找到只是第一步，做到，才重要。这又是一个艰难的旅程，有多少开发和测试是一个部门的？有多少测试是具备编码能力的？我相信自己问了这两个问题，很多人就默默的在心里放弃了。...你会发现其实就是没有单元测试的FIRST原则的F和T了。 F是什么？F是Fast，你会发现你的单元测试是会Fast，但是，无论如何你的自动化接口测试、自动化功能测试都很难像单元测试那么快。
一些最难跟踪的bug有部分是由那些静静失败并扩展而不是抛出错误的代码所导致的。例如，没有检查代码却返回错误的系统调用（如bind）。又如：解析代码在它遇到错误元素的时候只是返回而非抛出错误。...测试 作为一个开发人员，直到要测试了我才会去处理功能。至少，这意味着每一行新的或改变了的代码行至少已经被执行过一次。此外，单元测试和功能测试都很不错，但还不够。...新的功能也必须进行测试，并在类似于产品的环境中探索。只有这样，我才能说我完成了一个功能。下面是我经历过的bug所教会我的关于测试的一些重要的经验教训： 8.零和null。...当曾经可以正常工作的东西停止工作，那么这通常是因为最近改变的东西所导致的。在一个案例中，最近的改变只是日志记录，但是日志中的错误却导致了一个更大的问题。...我见过很多这样的情况，让我明白，因为不寻常的配置或意料之外的用法而导致不可思议的事情的发生，而我默认的假设是，他们是正确的，程序是错误的。 18.测试修复。如果bug修复已准备就绪，那就必须进行测试。
这个模式的前提是所有测试都应该遵循默认布局。测试系统所必需的全部条件和输入都应该在测试方法开始的时候被设置（Arrange）。...如果要做这些，那么我们不得不去了解这些方法返回对象的详细信息。而我们的单元测试就会开始变形，逐渐成为一大堆不能维护的、脆弱的代码。...然后，如果其中一个断言失败了，我们能够确定测试系统中的哪部分失败了吗？是 foo.bar(100.0) 方法失败了？还是 foo.getBar() 或者 foo.isValid() 方法失败了？...而示例中的产生的这种麻烦，已经使得我们的目的落空。如果测试失败，我们不得不运行调试器来找到到底什么地方失败了，那么我们的处境也会变得困难。...希望你能够希望我们讨论过的这些原则，并且能够看到它们是如何潜移默化地让你热爱编写单元测试。是的，我是说“热爱”，因为我相信编写单元测试是高品质软件的基本要求。
当然单元测试并非在前后端分离流行之后才有，它很早就存在，只是鲜有人重视且真的能够用好它。...有人可能写过单元测试，但是却不知道为什么要写单元测试，有人知道为什么要写单元测试，但不确定如何写才是好的单元测试。但是对于“测试” 我们每个人都轻车熟路， 你看看下面的功能是否似曾相识？ ?...而我们只是在脑海中预想了一下它应该如何工作的，应该给我什么结果等，然后运行一下，咦，还真是这样的，那我们的测试就算通过了。...当单元测试失败的时候，应该一眼就看出是因为什么原因导致的这个失败 一个测试方法只验证一个case，只用一个Mock，Stub可以是多个 好的命名，最好是可以从方法名看出以下三个要素（所以一般我们采用三段命名法...如果我邮箱不填？用户名不填？ 边界测试 如果我的邮箱名称或者用户名长度超过最大限制？
“别人”，是指相关代码或环境，“我”，是指正在编写或测试的代码单元。 单元测试为啥能提高代码质量呢?由于每个单元有独立的逻辑，做单元测试时需要隔离外部依赖，确保这些依赖不影响验证逻辑。...（5）独立执行路径测试从以下几点考虑行为手段： 1）死代码； 2）精度错误（比较运算错误、赋值错误）； 3）表达式的不正确符号。 单元测试从上述五个行为出发，来验证代码所对应的目的与预期。...测试框架会保存测试失败的信息，运行teardown逻辑，然后接着运行下一个测试。 断言让单元测试拥有了自动化测试的能力。...姿势2：干掉单元测试的天敌—可测性 单元测试效益特别高，方法看起来也很简单，但却尝试的多，成功实施的少，为什么呢？主要原因在于难于突破可测性问题。...一个函数要“可测”，要做到两方面：第一是能够独立运行，第二是要能够覆盖输入分类。为什么要覆盖输入分类呢？因为单元测试的目标是覆盖代码单元的功能逻辑，要做到覆盖功能逻辑，就要覆盖输入的所有分类。
在《Learning From Your Bugs》一文中，我写了关于我是如何追踪我所遇到的一些最有趣的bug。最近，我回顾了我所有的194个条目（从13岁开始），看看有什么经验教训是我可以学习的。...一些最难跟踪的bug有部分是由那些静静失败并扩展而不是抛出错误的代码所导致的。例如，没有检查代码却返回错误的系统调用（如bind）。又如：解析代码在它遇到错误元素的时候只是返回而非抛出错误。...测试 作为一个开发人员，直到要测试了我才会去处理功能。至少，这意味着每一行新的或改变了的代码行至少已经被执行过一次。此外，单元测试和功能测试都很不错，但还不够。...当曾经可以正常工作的东西停止工作，那么这通常是因为最近改变的东西所导致的。在一个案例中，最近的改变只是日志记录，但是日志中的错误却导致了一个更大的问题。...我见过很多这样的情况，让我明白，因为不寻常的配置或意料之外的用法而导致不可思议的事情的发生，而我默认的假设是，他们是正确的，程序是错误的。 18.测试修复。如果bug修复已准备就绪，那就必须进行测试。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
即时通信 IM
ICP备案
对象存储
实时音视频
