赛普拉斯usb开发板_开发人员应推动赛普拉斯的E2E测试

赛普拉斯usb开发板

所有软件公司都致力于生产优质的产品。 旅程始于一种有效的产品。 软件 正确性通常被定义为 遵守软件规范。 在大多数情况下，不可能进行正式验证。 因此，我们通常强加功能的正确性 与 测试覆盖率 。

为了迎接挑战，公司培育了一种文化， 鼓励各种堆栈的开发人员 编写范围不同的测试 。 这种文化通常催生了开发人员编写的大量静态，单元和集成测试。 但是， 许多公司不 向其开发人员 提供 编写端到端（E2E） 测试的工具 。

在一个日益复杂的分布式系统世界中， 这够了吗？

动机

孤立的 组件测试 可能无法发现关键的错误 。 我们所有人都曾经面对过一个看起来面面俱到的严峻现实，即一个看起来面面俱到的新功能因讨厌的服务间错误而崩溃和烧毁。

如果开发人员可以编写一些E2E测试来验证用户是否拥有我们想要提供的体验，那么世界是否会变 得更美好？ 在许多公司中，这些测试属于软件自动化工程师的领域。 传统上，它们是在专用框架（例如Selenium）上编写的。

因此，他们是 对开发者基本上不熟悉 。 对于前端工程师，有时他们是用不同的编程语言编写的。 这种人为的边界限制了开发人员充分利用自动化测试 。

开发人员驱动的端到端 测试的优势显而易见：

更高的产品质量和可维护性 -通过E2E测试来补充开发人员的工具箱，可以鼓励并改善测试驱动开发的采用，并带来诸多好处 。 将这些测试作为主要任务的一部分而不是附录，可以确保该功能在发布之前已被真正涵盖。

拥有所有权的氛围 -拥有功能的整个生命周期可培养对成品质量的责任，并增强开发人员的感知影响力。 依赖外部测试（无论是自动还是手动）都会降低开发人员的责任感。 这带来了一种浅薄的主人翁意识和“不是我的问题”心态的风险。

加快开发速度 -通过将整个测试金字塔或奖杯分配给开发人员来支持整体测试方法，从而加快了开发速度。 首先，它消除了在开发过程中涉及另一方的开销。 其次，它防止流水线延长测试冗余。 毕竟，在现有的精益集成测试就足够了的情况下，无需在E2E测试中为构建管道增加负担。

降低运营成本 -补充一点，更少的测试（尤其是庞大的Selenium套件）需要更少的执行资源。

解决方案

使E2E测试成为常见商品 。 为开发人员提供轻便，简单的工具和方法，以启动 测试他们的产品。

成功之路

什么工具 ？ 我不会重复任何现有的E2E测试框架所带来的诸多折衷。 该主题不在本故事的讨论范围之内，并且已被广泛讨论 （例如， Selenium与Puppeteer ， TestCafe与Cypress ）。 相反，我将分享我的流程要点：

与Selenium合作后，我觉得这不是一个合适的解决方案。 WebDriver的庞大性及其有限的模拟功能使其对于TDD而言是不切实际的，并且该框架的学习曲线对于无处不在的工具而言过于陡峭。

在同一角落是更新的Puppeteer框架，我在该框架中拥有浏览器自动化的经验。 不幸的是，它与最近发布的Playwright一起遭受许多相同的痛苦。

TestCafe框架虽然打勾了许多框，但使用的测试范例对于习惯了通用测试框架的前端开发人员而言可能并不自然。

这些框架中的某些空白可以由CodeceptJS填补， CodeceptJS是一种通用包装器。 但是，它的有限人气使其在企业环境中的承诺更加艰巨

最终，我为Cypress确定了POC。

为什么选择 柏树 ？ 用他们自己的话说 ：

我们的使命是建立一个蓬勃发展的开源生态系统，该生态系统可以提高生产力 ， 使测试变得愉快 ，并为开发人员带来快乐 。 我们对自己负责，以倡导真正有效的测试过程 。

首先，我觉得赛普拉斯是开发者幸福的选择 。 毕竟，愉悦感决定了新工具和新想法的采用或失败。 如果我们要获得开发人员推动的端到端测试的成果， 开发者应该 要编写测试 。

其次，我发现赛普拉斯的可扩展性具有极大的潜力，可以满足我产品某些独特的测试要求。 第三，其受欢迎程度和社区支持使其成为未来的更安全选择 。

通过适当的包装和扩展， 赛普拉斯 可以帮助开发人员将测试集成到他们的日常工作流程中 。 作为开发人员的代码，一个简单的终端命令可以启动一个令人印象深刻的测试运行程序 ，该运行程序在真实的浏览器上执行测试。

然后可以在您选择的CI管道中使用相同的测试运行程序，在相同的运行环境中使用。 结果以精美的报告形式显示，其中可能包括屏幕截图，测试运行记录以及您要附加的其他内容。

归根结底， 赛普拉斯提供了什么？

超快的速度 - 快速 。 足够快，可以连续测试我们的代码。 预先，这是因为赛普拉斯是提到的唯一在浏览器中运行的框架。 但是，其主要性能提升之一来自内置和扩展的后端模拟功能。

在E2E测试中，当您可以重播录制的页面启动时，为什么浪费宝贵的时间等待按钮被单击？ 在更有限的测试范围内，当适当的JSON响应足够时，为什么还要等待服务器执行复杂的查询？

易于采用和使用 -新工具始终涉及学习曲线。 赛普拉斯开箱即用，利用了无处不在的Mocha ， Chai和Sinon测试堆栈。 如果这不是您的需要，那么您可能会享受一些令人兴奋的插件支持，包括Jest风格的断言 ， React Testing Library甚至Gherkin语法 。

整体方法 —赛普拉斯不仅限于E2E测试。 它可以支持所有范围的测试。 除了通过修改后端模拟的程度来确定先天范围外，还有用于组件测试的专用插件 。

调试简单-可读的错误消息和堆栈跟踪，对开发人员工具的访问，测试记录和快照，都可以带来简单的调试体验，这使您不太可能怀疑测试为什么失败。

准备好集成 -开发人员可以在CI管道中运行与开发期间相同的测试。 赛普拉斯为大多数提供商提供了示例 。 官方Docker映像可用于在本地和CI中运行Cypress。

可扩展性 —赛普拉斯是一个受欢迎的项目，得到了企业的支持和社区的大力支持。 生态系统已经包括许多插件 ，从身份验证到框架扩展。 这种可扩展性扩展给您-使用现有API 编写插件相对容易。 丝毫不会阻止您使Cypress满足您的需求。

为了成功将赛普拉斯集成到工作流程中 ，可能需要进行自定义过程 在其产品和开发程序的范围内使其尽可能地易于访问 。

可访问性可以转换为最少的设置，舒适且熟悉的配置，即用型命令，对首选测试堆栈语法的支持，性能调整和CI集成。

结论

正如我所看到的， 授权软件开发人员进行E2E测试可以对以下方面产生深远的影响 研发和组织整体。

重要的是要注意， 端到端测试不会取代组件测试范围 ，而是会释放出整体测试方案 。 这种方法可提高产品质量和可维护性 ， 营造所有权氛围， 加快开发速度并降低运营成本 。

例如，开发组件的开发人员应该使用E2E测试来补充单元测试，该测试从用户的角度检查其功能。

为此，我发现赛普拉斯致力于开发人员驱动的测试 。 它以惊人的速度和易用性为后盾 有 的 保持开发人员满意并激发采用这种方法的潜力。 再加上赛普拉斯令人印象深刻的可扩展性， 任何人都可以自由地满足其需求 。

我想强调一点，即E2E开发人员驱动的测试不一定要以外部人员 （例如软件自动化工程师） 的自动化为代价 。 外部测试的好处是，它的根源在于避免让狐狸守护鸡舍的愿望。

翻译自: https://hackernoon.com/developers-should-drive-their-e2e-tests-to-cypress-ux3w3yeo

赛普拉斯usb开发板