- 综合排序
- 最热优先
- 最新优先
- 来自专栏海怪的编程小屋
前端单测，我们应该测什么？
相信很多前端开发在写单测的时候，最大的问题就是：“我应该测什么东西？” 没错，解决问题不是最难的，发现问题才是！知道要测哪个远比怎么测重要很多！ 但是知道如何测试只是成功的一半，知道要测什么才是更重要的另一半。 永远记住为什么我们要测试 我们写测试是因为要确保我们的应用程序在用户使用它们时能够正常工作。 很多人在做 React 代码测试时，经常会想到一些让他们不断测 “实现细节” 的测试点。 （比如：firebase、redux store、router、media query） 该从何测起？ 现在我们都清楚应该要对单测组件或者页面组件测什么了，那你该从何测起呢？
1K20编辑于 2022-05-09 - 来自专栏Chromium学习
单测：Google Test框架
Google Test是一个流行的C++单元测试框架，它提供了丰富的断言和测试工具，用于编写和运行单元测试。基于流行的 xUnit 架构
1.6K10编辑于 2024-03-22 - 来自专栏腾讯移动品质中心TMQ的专栏
Android终端单测杂烩
以上两种，先看Java再跟进Kotlin的话，体感大概一~二周差不多可以读懂开发代码+写一些单测用例。有相关经验会更快一些。 给测试同学-Gradle 实际开始投入单测之后发现有不少坑都在Gradle里面，所以需要大致了解Gradle，磨好刀再砍柴。基础资料搜索一下网络还是比较全的。 整体编译情况下这么操作是ok的，但是单测场景下测试单个模块时就可能导致找不到实现。 单测中获取context Instrument test里面经常要获取context，对于单测来说可以直接使用InstrumentationRegistry.getInstrumentation.context 覆盖率工具 a) Local unit test 如果单测用例是本地用例，可以直接使用AS自带的工具。
2.2K40发布于 2019-07-11 - 来自专栏海怪的编程小屋
前端单测，为什么不要测 “实现细节”？
相信不少同学在写单测的时候，最大的困扰不是如何写测试代码，而是：“应该测什么？”，“要测多深入”，“哪些不该测”。 最近在给 React 组件写单测的时候，发现了 Kent （React Testing Library 的贡献者之一）的 《Testing Implementation Details》 这篇文章，里面对 “为什么不要测代码实现细节？” 因为我们只测了业务中非常小的一个实现细节，所以为测这个实现细节，我们不得不补另外很多测试用例，来测其它毫不相关的实现细节，那这样我们永远都不可能补完所有实现细节的测试代码。 用假数据在购物车中渲染表单，点击结账按钮，确保假 /checkout 请求执行，并获取成功的响应，确保可以展示成功消息） 将这份手动操作清单转化成自动化测试 好了，这篇外文就给大家带到这里了，希望对大家在单测中有所帮助
1.4K50编辑于 2022-03-30 - 来自专栏软件测试那些事
单测实例-void方法验证
单元测试-更新项目 利用MeterSphere更新项目的方法来介绍 1）如何对void方法进行测试 2）如何捕获写库入参并验证 3）继续使用Mockito-inline来mock静态方法 以下是被测对象 sessionUtils.when(() -> { SessionUtils.getCurrentWorkspaceId();}).thenReturn("id"); //调用被测方法
3.8K10发布于 2020-12-22 - 来自专栏每日一善
rust的单测和文档
测试的目的： 发现问题 保证项目长期的健壮性和可维护性 单元测试是重构的保证，编写无状态函数 rust的单元测试 内置测试框架：属性和宏 断言宏assert!, assert_eq!,assert_ne!,debug_assert! 运行测试 #[test] fn basic_test() { assert!(true); } //RUST_TEST_THREADS = 1 //rustc --test xxx.rs 隔离测试单独构建测试的文件夹和src同级 cargo test 故障测试 #s
70940编辑于 2022-05-04 - 来自专栏TopCoder
如何优雅地执行dubbo单测
很多小伙伴所在的公司是基于Dubbo来构建技术栈的，日常开发中必不可少要写dubbo单测（单元测试），如果单测数据依赖已有的外部dubbo服务，一般是mock数据，如果数据比较复杂，其实mock数据也是一个不小的工作量 那有没有更好的单测方式来代替我们完成”mock“数据功能呢，这时可以借助dubbo telnet功能，获取真实数据用在单测中使用。 本文会先讨论如何使用基于dubbo telnet的代理工具类（DubboTelnetProxy），然后再讨论下mockito+DubboTelnetProxy如何进行多层次的单测，最后分析下如何让单测变得更加智能 （ps：关于dubbo和mockito这里就不展开讨论了，具体可以参考对应资料~） 1 Dubbo单测现状 dubbo单测其实和非dubbo单测的流程是一样的，初始化待测试类和单测上下文，打桩然后调用， 上述代码不足点是：目前每次dubbo调用都会新建telnet连接，对于单测来说是OK的，后续如果用于本地压测或者调用频繁测试场景，考虑复用连接或者使用netty client bootstrap方式避免每次都新建连接
1.7K10发布于 2020-01-02 - 来自专栏人人都是架构师
Go单测系列2—网络测试
在上一篇《Go单测系列1—单元测试基础》中，我们介绍了Go语言编写单元测试的基础内容。 《Go单测从零到溜系列》的示例代码已上传至Github，点击https://github.com/go-quiz/golang-unit-test-demo 查看完整源代码。
85430编辑于 2023-09-10 - 来自专栏腾讯IMWeb前端团队
Jest + React Testing Library 单测总结
加上之前实际的工作中，也没有太多的写测试的经历，所以当自己需要对组件库补充单元测试的时候，发现并不能照葫芦画瓢来写单测。 一时不知道该如何下手，也不知道如何编写有效的单测，人有点懵，于是就比较粗略地研究了一下前端组件单测。 1.1 单测的目的 在频繁的需求变动中可控地保障代码变动的影响范围 提升代码质量和开发测试效率 保证代码的整洁清晰 ...... 总之单测是一个保证产品质量的非常强大的手段。 1.3 组件单测须知 在开始进行组件单测的时候，有几个因素我们需要考虑： 组件是否按照既定的条件 / 逻辑进行渲染 组件的事件回调是否正确 异步接口如何校验 异步执行完毕后的操作如何校验 ...... 就像开头提到的，本文只是“比较粗略”地浏览了 Jest + RTL，相较于整个前端单测来说只是冰山一角。
5.8K20编辑于 2022-06-29 - 来自专栏前端精读评论
精读《如何为 TS 类型写单测》
如何为 TS 类型写单测呢？ 但这种单测并不是我们要讲的类型。 讨论地址是：精读《如何为 TS 类型写单测》· Issue #446 · dt-fe/weekly 如果你想参与讨论，请 点击这里，每周都有新的主题，周末或周一发布。
97410编辑于 2022-11-21 - 来自专栏人人都是架构师
Go单测系列6—goconvey的使用
在上一篇《Go单测系列5—monkey打桩测试》中，我们介绍了如何在单元测试中使用monkey对函数和方法进行打桩。 在这一篇中我们将介绍一个人性化的单元测试利器——goconvey。 《Go单测从零到溜系列》的示例代码已上传至Github，点击https://github.com/go-quiz/golang-unit-test-demo 查看完整源代码。
65730编辑于 2023-09-10 - 来自专栏后端系统和架构
Go 单测高级篇：Golang 单测原理深入理解
Go 单测高级篇：Golang 单测原理深入理解我们经常在做 Go 单测的时候，会用到两种库，gomonkey or mocker，然后在做单测的时候会通过一些所谓的 mock 方法。 不知道大家有没有想过，Go 的单测，为何能够 mock 住呢？具体是怎么实现的呢？然后这个 mock 的真正含义又是什么呢？ Go 单测的一些基本使用就不讲了，关于 Go 单测的基本介绍和使用可以查看我的另外两篇入门文章：• 《Go 单测入门篇：Golang 单元测试基本使用》• 《Go 单测入门篇：单元测试类型和 Golang 如下一、单测中常见的 5 种测试替身1-1、5 种测试替身• Dummy Object• 指在测试中必须传入的对象，而传入的这些对象实际上并不会产出任何作用，仅仅是为了能够调用被测对象而必须传入的一个东西 这样，runtime 运行时其实就可以指向 mock 的 interface 实现来满足我们的单测诉求。2-3、为何测试代码可以 mock 住 ？
1.9K20编辑于 2022-12-06 - 来自专栏人人都是架构师
Go单测系列4—mock接口测试
在上一篇《Go单测系列3—数据库测试》中，我们介绍了如何使用go-sqlmock和miniredis工具进行数据库测试。 除了网络和数据库等外部依赖之外，我们在开发中也会经常用到各种各样的接口类型。 《Go单测从零到溜系列》的示例代码已上传至Github，点击https://github.com/go-quiz/golang-unit-test-demo 查看完整源代码。 testing.T) { // 创建gomock控制器，用来记录后续的操作信息 ctrl := gomock.NewController(t) // 断言期望的方法都被执行 // Go1.14+的单测中不再需要手动调用该方法
1.2K30编辑于 2023-09-10 - 来自专栏人人都是架构师
Go单测系列5—使用monkey打桩
在上一篇《Go单测系列5—mock接口测试》中，我们介绍了如何在单元测试中使用gomock和gostub工具mock接口及打桩。 《Go单测从零到溜系列》的示例代码已上传至Github，点击https://github.com/go-quiz/golang-unit-test-demo 查看完整源代码。
49700编辑于 2025-01-18 - 来自专栏KIWI的碎碎念
【spock】单测竟然可以如此丝滑
至少在我看来，单测有如下几点让我喜欢不起来的理由。第一，要额外写很多很多的代码，一个高覆盖率的单测代码，往往比你要测试的，真正开发的业务代码要多，甚至是业务代码的好几倍。 这让人觉得难以接受，你想想开发 5 分钟，单测 2 小时是什么样的心情。而且并不是单测写完就没事了，后面业务要是变更了，你所写的单测代码也要同步维护。 第二，即使你有那个耐心去写单测，但是在当前这个拼速度挤时间的大环境下，会给你那么多写单测的时间吗？写一个单测的时间可以实现一个需求，你会如何去选？ 最后得出了一个无可奈何的结论，单测是个让人又爱又恨的东西，是不想做但又不得不做的事情。虽然我们没办法改变要写单测这件事，但是我们可以改变怎么去写单元测试这件事。 2. 在使用其它单测框架时，与之类似的是 assert 。
1.8K30发布于 2020-04-08 - 来自专栏海怪的编程小屋
来聊聊我们为什么要写单测
对于我个人来说，我是非常喜欢写单测的。最近还买了本《软件测试》的书，算是再次复习一下大学时学过的专业课，平时在捣鼓一些个人项目的时候也会做一些基础的单测。 一谈到单测，可能大家的第一反应都是敬而远之。 所以，今天我会尝试从另外一些角度来讨论单测可以给我们带来哪些好处。 单测所保障的不仅仅只是代码的正确性，毕竟大家在边开发边 Debug 的时候已经能验证 99% 的正确性了，而单测更大的地方在于 让我们不得不去思考到一些异常情况 ，这无形中就能增强代码的质量。 当然，本文也并非要让大家马上给项目上单测，只是希望大家能够多尝试自己领域之外的东西，不要固步自封。对个人而言，多练习写单测能力肯定是好处多于坏处。 好了，这篇文章就给大家带到这里。
69520编辑于 2022-03-29 - 来自专栏Go
Go系列：这个单测为什么过不了
背景 最近工作中需要写mysql相关单测，但是有个case一直报错，请看如下示意代码 user的model定义代码，包括user结构定义和一个ListUser方法package models import User, error) { var users []User err := db.Find(&users).Error return users, err } - 下面对ListUsers写一个单测 WillReturnRows(rows) users, \_ := ListUsers(gormDB) assert.Equal(t, 1, len(users)) }) } } 单测总体也比较简单
30710编辑于 2024-11-21 - 来自专栏陈树义
业务变化快，有必要写单测吗？
在前面一篇文章（单测无用论，这是真的吗？）中，我提到判断单测是否适用的几个维度，其中有一个就是业务变化情况。理论上来说，业务变化快，改单测成本高，维护成本也高。 按理说，如果不是对功能质量有很高的要求，感觉是可以不写单测的。 但事实真的是这样吗？针对这个问题，我与单测群的小伙伴们进行了讨论，大家都非常积极地发表了看法。 就如我上面所说：我们不写单测的原因，是因为单测会拉长交付周期，使得交付速度变慢。但如果交付速度提高了，可是交付质量下降了，可以接受吗？ 我想，对于有些规模的公司来说，交付质量一定比交付速度更重要。 如果我们站在编程者的角度看，你现在不写单测，很可能只是把现在写单测的时间挪到后面修 bug 而已。 除非你的代码质量真的很高，高到及时不写单测一个 bug 都没有，那确实没必要写单测了。 从觉得单测没啥用，到觉得单测还有点用，再到业务变化不大可以写写单测，最后到即使业务变化快也要写单测，深感单测写得越多，越能感觉到单测的好处。
1K20编辑于 2023-03-15 - 来自专栏陈树义
大家都说单测没啥用，这是真的吗？
工作了快 10 年了，跟研发小伙伴聊起单测，绝大多数人的反应是 —— 单测没啥用，写单测就是为了应付单测覆盖率的 KPI 指标。 恰好我最近在团队落地单测相关的内容，经过一段时间的持续迭代，我对单测的看法也从一开始的 没啥用 到后面的 好像有点东西，再到最后的 卧槽，真牛逼！。基本上随着单测写得越深入，我对单测就越发重视。 为啥说单测没啥用？ 那些说单测没啥用的小伙伴，我想大概率是不知道怎么写单测，没写过真正合格的单测，而只是用单测来凑凑单测覆盖率的 KPI 指标。 没有选择合适的单测框架，单测代码写得业务代码还多，这可咋整？ 等等 总而言之，这一切的原因导致没写出合格的单测，没办法让单测为他们带来好处，于是它们对单测充满了失望，最终就觉得单测没用。 单测的适用场景 看了这么多，知道了单测有那么多好处，但又单测又不能包治百病，那单测到底适合在什么场景使用呢？ 在我看来，对于是否要推行单测，以及单测的要求高低，其实取决于下面几个维度： 1.
49430编辑于 2023-03-09 - 来自专栏陈树义
关于单测技术选型，聊聊我的思考
对于单测来说，目前常用的单测框架有： JUnit Mockito Spock PowerMock JMockit TestableMock 其中 JUnit 不支持 Mock，因此基本不会只用 JUnit 缺点：代码不够简洁、没有统一的单测结构、不支持静态方法和私有方法 Mock。 我们重视写单测，但是又不希望写单测花费太多时间，毕竟业务才是第一位的。因此，我们希望单测代码尽可能简洁、可维护。 基于这个原因，我们选择了 Spock 框架作为朝昔后端的单测框架解决方案。 同样是用于测试计算器的加法函数的单测用例，使用 Spock 框架编写的单测如下代码所示。 ，从而提高单测的可读性，使得单测更加容易维护。
1.1K10编辑于 2023-04-17
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号