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

在单元测试中有多个断言是不好的做法吗?

是的,在单元测试中,多个断言是不好的做法。

原因如下:

  1. 代码可读性降低:在单元测试中,每个测试函数应该只关注一个特定的功能或代码块。多个断言会导致测试代码混乱,难以理解。
  2. 测试边界条件:多个断言可能会导致测试没有覆盖到重要的边界条件,从而使得测试用例失效。
  3. 代码维护:当其他开发人员阅读和维护测试代码时,多个断言可能会导致混淆和错误。

推荐的解决方案:

在一个单元测试中,确保每个测试函数只关注一个特定的功能或代码块。这样可以提高代码的可读性和测试效果。如果需要测试多个条件,可以考虑将它们分别封装在不同的测试函数中。

以下是一个示例:

代码语言:python
代码运行次数:0
复制
# Test function for function A
def test_function_a():
    assert function_a() == "expected_result"

# Test function for function B
def test_function_b():
    assert function_b() == "another_expected_result"

# Test function for function A with different input
def test_function_a_with_different_input():
    assert function_a(input_data) == "unexpected_result"

在上面的示例中,每个测试函数只关注一个特定的功能。测试用例包括不同的输入数据,以确保测试函数能够处理各种边界条件。

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

相关·内容

python中有多个对应库可以操作Pdf文件,其中最常用Pypdf2

PDFPortable Document Format简称,意为“可携带文档格式”,由Adobe Systems用于与应用程序、操作系统、硬件无关方式进行文件交换所发展出文件格式。...python中有多个对应库可以操作Pdf文件,其中最常用Pypdf2PyPDF一个操作pdf模块,现在最常用版本是PyPDF2;需要注意,这个库不能操作pdf获取文字信息PyPDF2介绍...PyPDF2PyPdf2中有两个模块,分别是:读取库 PDFFileReader操作库 PdfFileWriter1、使用PDFFileReader可以获取pdf文件基本信息,还可以获取到每一页pdf...PageObject:PdfFileReader加载pdf文件后,获取每一页都会被转换为PageObject对象,对于Pdf操作,实际就是操作PageObject对象;下面PageObject...90 度增量rotateCounterClockwise(angle)逆时针旋转页面,angle必须 90 度增量scale(sx, sy)缩放页面scaleBy(factor)按固定XY轴比例缩放页面

87610

C 语言 C++ 中 assert 用法

assert不管屏蔽还是启用状态下都不能对我们本身代码有所影响,这样刚才我们代码中使用assert(i++)就不行,因为如果禁用了assert,那i++就不能执行;正确做法应该是:assert...每个assert只检验一个条件,因为同时检验多个条件时,如果断言失败,我们就无法直观判断哪个条件失败; 无法直观判断哪个条件失败: assert(nOffset>=0 && nOffset+nSize...,就像我们上面的代码改变了i变量,实际编写代码过程中不能这样做; 例如: assert(i++ < 100) 不好:这是因为如果出错,比如在执行之前i=100,那么这条语句就不会执行,那么i++...断言assert 仅在Debug 版本起作用宏,它用于检查"不应该"发生情况。 5....单元测试必须使用断言;另外除了类型检查和单元测试外,断言还提供了一种确定各种特性是否程序中得到维护极好方法;

2.9K00
  • C语言C++中assert用法

    assert不管屏蔽还是启用状态下都不能对我们本身代码有所影响,这样刚才我们代码中使用assert(i++)就不行,因为如果禁用了assert,那i++就不能执行;正确做法应该是:assert...每个assert只检验一个条件,因为同时检验多个条件时,如果断言失败,我们就无法直观判断哪个条件失败; 无法直观判断哪个条件失败: assert(nOffset>=0 && nOffset+nSize...不能使用改变环境语句,就像我们上面的代码改变了i变量,实际编写代码过程中不能这样做; 例如: assert(i++ < 100) 不好:这是因为如果出错,比如在执行之前i=100,那么这条语句就不会执行...断言assert 仅在Debug 版本起作用宏,它用于检查"不应该"发生情况。 5....单元测试必须使用断言;另外除了类型检查和单元测试外,断言还提供了一种确定各种特性是否程序中得到维护极好方法;

    1.4K20

    C语言 | C++中assert用法

    assert不管屏蔽还是启用状态下都不能对我们本身代码有所影响,这样刚才我们代码中使用assert(i++)就不行,因为如果禁用了assert,那i++就不能执行;正确做法应该是:assert...每个assert只检验一个条件,因为同时检验多个条件时,如果断言失败,我们就无法直观判断哪个条件失败; 无法直观判断哪个条件失败: assert(nOffset>=0 && nOffset+nSize...不能使用改变环境语句,就像我们上面的代码改变了i变量,实际编写代码过程中不能这样做; 例如: assert(i++ < 100) 不好:这是因为如果出错,比如在执行之前i=100,那么这条语句就不会执行...断言assert 仅在Debug 版本起作用宏,它用于检查"不应该"发生情况。 5....单元测试必须使用断言;另外除了类型检查和单元测试外,断言还提供了一种确定各种特性是否程序中得到维护极好方法;

    1.8K88

    Selenium2+python自动化51-unittest简介

    前言 熟悉java应该都清楚常见单元测试框架Junit和TestNG,这个招聘需求上也是经常见到。...翻译:python单元测试框架,基于javajunit测试框架 ? 二、简单用法 1.可以把上图这段代码copy出来,单独运行,看看测试结果。...5.注释里面有句话很重要,这个要敲下黑板记笔记了:## test method names begin 'test*' --翻译:测试用例名称要以test开头 6.然后断言assert,这里断言方法...assertEqual-判断两个是否相等,这个断言可以是一个也可以是多个 7.if下面的这个unittest.main()运行主函数,运行后会看到测试结果(跑了两个用例耗时0.000秒,两个用例都通过...2.有很多小伙伴不知道断言怎么写,断言其实就是拿实际结果和期望结果去对比,对比方法很多,这里只是举最简单一个判断相等方法。 ?

    80160

    c++代码整洁之道

    更干净原则(自命名):离开露营地时候,应让露营地比你来之前还要干净,当发现代码中有需要改进或者风格不好地方,应该立刻改掉,不要care这段代码原作者谁,也不要care这是谁模块,代码所有权集体...保证单元测试独立性,每个测试单元都是独立,不依赖于其它测试单元,不要构建测试单元上下文,上面的测试单元出问题影响到下面的单元测试设计很不友好。...尽量保证一个测试单元使用一个断言,保证测试单元内部一个相对独立性,上面的断言阻碍了下面的断言测试也是不好设计。...单元测试尽量不要涉及数据库,数据库状态全局,测试不能保证独立性,而且数据库访问也是缓慢,影响单元测试速度,如果真的需要可以模拟数据库在内容中进行测试,其实通常是系统集成和系统测试级别时去测试数据库...编辑器 团队可以统一使用相同编辑器,个人目前使用VS Code编辑器,同时每个项目使用统一.clang_format文件,统一规范代码格式,所有的换行符都要用LF格式,不要用CRLF格式,右下角可以设置

    1.1K10

    如何写好 GO 语言单元测试

    在上例,比较正确做法: ? 避免无意义重复 让我们看这样一个例子 ?...设计 UT 时,我们要问问自己,重复执行 doSomeThing 多次会带来不同结果,如果总是同样结果,那么 doSomeThing 只做一次就足够了。...如果确实会出现不同结果,那简单重复 10000 次不仅浪费了有限 CPU 等资源,也比不上精心设计不同断言能给我们带来更多好处。  在上例,比较正确做法: ? 尽量避免断言时间结果 ?...除非我们就是测试 Sleep 之类跟时间有关函数,否则对时间断言通常总是能被转化为跟时间无关断言。一定要断言时间的话,断言超时比断言及时更不容易出错。...比如上面的例子,我们没办法断言它一定在 1 秒内完成,但是大概能断言它在 10 微秒内完不成。 尽量避免依赖外部服务 即使我们十分确信某个公有云服务在线 UT 中依赖它也不是一个好主意。

    2K20

    重温《单元测试艺术》,总结常用知识点

    前言 关于单元测试定义和好处可以借用Stephen Cleary一段话来概括: 单元测试现代开发基础。...我编写单元测试时,我会对代码更有信心。已测试代码中更易于添加功能或修复 Bug,因为代码发生更改时,单元测试起着安全网作用。 前几个月重温了单元测试艺术。...单元测试组成 单元测试通常包含三个行为: 准备(Arrange)队形,创建对象,进行必要设置; 操作(Act)对象; 断言(Assert)某件事情预期。...,《单元测试艺术》中有详细介绍,这里略过。...集成测试对一个工作单元进行测试,这个测试对被测试工作单元没有完全控制,并使用该单元一个或多个真实依赖物,例如事件、网络、数据库、线程或随机数产生器等。 集成测试和单元测试项目应该分开。

    1.5K31

    Go单测系列1—单元测试基础

    这是Go语言单元测试从零到溜系列教程第1篇,主要讲解Go语言中如何编写单元测试以及介绍了表格驱动测试、回归测试和单元测试中常用断言工具。...*_test.go文件中有三种类型函数,单元测试函数、基准测试函数和示例函数。...go test -run 单元测试结果表明split函数实现并不可靠,没有考虑到传入sep参数多个字符情况,下面我们来修复下这个Bug: package base_demo import "...回归测试 我们修改了代码之后仅仅执行那些失败测试用例或新引入测试用例错误且危险,正确做法应该是完整运行所有的测试用例,保证不会因为修改代码而引入新问题。...安装 go get github.com/stretchr/testify 使用示例 我们单元测试时候,通常需要使用断言来校验测试结果,但是由于Go语言官方没有提供断言,所以我们会写出很多if.

    32620

    码农,你真的了解TDD和BDD

    严格地说,“先写测试、后写代码”做法叫测试先行开发(Test First Development),而不是测试驱动开发。 测试驱动开发不也是先写测试后写代码?二者之间有什么区别呢?...因为很多单元测试框架运行测试过程中,测试不过时会用红色展示测试结果,而通过时则采用绿色进行展示,这已经成了单元测试框架约定俗成规则。...测试驱动开发中,重构与测试相辅相成:没有测试,修改代码只能提心吊胆;没有重构,代码混乱程度会逐步增加,测试也会变得越来越不好写。 现在,你已经理解了测试驱动开发不只是“先写测试,后写代码”。...我们日常工作中也不妨多想想, 有哪些做法,如果把它推向极致会是什么样子。 这种想问题方式会在很大程度上拓宽你思路。 说完了TDD,那什么BDD呢?...单元测试框架写测试方式更多面向具体实现,这种做法层次很低,BDD 希望把这个思考层次拉高。拉到什么程度呢?

    88010

    实例入门 Vue.js 单元测试

    单元测试软件开发过程中要进行最低级别的测试活动,软件独立单元将在与程序其他部分相隔离情况下进行测试。...1.2 断言(assertions) 断言单元测试框架中核心部分,断言失败会导致测试不通过,或报告错误信息。...比如一个方法可能依赖另一个方法执行,而后者对我们来说是透明。好做法使用stub 对它进行隔离替换。这样就实现了更准确单元测试。...其中值得注意小经验,一一些异步更新(比如代码中有延时)后正确使用 wrapper.vm....单元测试可以为我们开发和维护提供基础保障,使我们思路清晰、心中有情况下完成对代码搭建和重构。 封装好则测试易,反之不恰当封装让测试变得困难。

    2.9K20

    unittest测试框架组成_unittest接口自动化

    作为单元测试框架, unittest 也是可以对程序最小模块一种敏捷化测试。自动化测试中,我们虽然不需要做白盒测试,但是必须需要知道所使用语言单元测试框架。...:单元测试用例,TestCase 编写单元测试用例最常用类 test suite:单元测试用例集合,TestSuite 最常用类 test runner:执行单元测试 test report:...,这些相关测试用例称为一个测试用例集,unittest中用TestSuite 类来表示。...如果一个py文件中有10个case,就需要增加10次 2.1.2 makeSuite()和TestLoader()应用 unittest 框架中提供了makeSuite() 方法,makeSuite...unittest 单元测试库提供了标准xUnit 断言方法。

    48830

    如何避免自己写代码成为别人眼中一坨屎!

    笔者推荐三本经典书籍《代码整洁之道 》、《编写可读代码艺术》、《重构:改善既有代码设计》,下文重点将从注释、命名、方法、异常、单元测试多个方面总结了一些代码整洁最佳实践,大部分笔者总结于以上三本书中精华...一、注释 不要给不好名字加注释,一个好名字比好注释更重要; 不要“拐杖注释”,好代码 > 坏代码 + 好注释; 文件/类级别使用全局注释来解释所有部分如何工作; 一定要给常量加注释; 团队统一定义标记...; 某个公共函数调用私有函数紧随其后; 最理想参数零参数,最长不要超过三个入参,尽量不要输出参数: 如果函数传入三个及以上参数最好将其抽象为类; 标识参数十分丑陋,向函数传入布尔值用于区分不同业务做法很丑陋...,尽可能少设计临界区; 六、单元测试 不要怕单元测试方法名字太长或者繁琐,测试函数名称就像注释; 不要追求太高测试覆盖率,测试代码前面90%通常比后面10%花时间少; 使用最简单并且能够完整运用代码测试输入...;; 给测试函数取一个完整性描述性名字,比如 Test _; 测试代码与生产代码一样重要; 如果测试代码不能保证整洁,你就会很快失去他们; 每个测试一个断言,单个测试中断言数量应该最小化也就是一个断言

    53220

    如何避免自己写代码成为别人眼中一坨屎!

    笔者推荐三本经典书籍《代码整洁之道 》、《编写可读代码艺术》、《重构:改善既有代码设计》,下文重点将从注释、命名、方法、异常、单元测试多个方面总结了一些代码整洁最佳实践,大部分笔者总结于以上三本书中精华...一、注释 不要给不好名字加注释,一个好名字比好注释更重要; 不要“拐杖注释”,好代码 > 坏代码 + 好注释; 文件/类级别使用全局注释来解释所有部分如何工作; 一定要给常量加注释; 团队统一定义标记...; 某个公共函数调用私有函数紧随其后; 最理想参数零参数,最长不要超过三个入参,尽量不要输出参数: 如果函数传入三个及以上参数最好将其抽象为类; 标识参数十分丑陋,向函数传入布尔值用于区分不同业务做法很丑陋...,尽可能少设计临界区; 六、单元测试 不要怕单元测试方法名字太长或者繁琐,测试函数名称就像注释; 不要追求太高测试覆盖率,测试代码前面90%通常比后面10%花时间少; 使用最简单并且能够完整运用代码测试输入...;; 给测试函数取一个完整性描述性名字,比如 Test _; 测试代码与生产代码一样重要; 如果测试代码不能保证整洁,你就会很快失去他们; 每个测试一个断言,单个测试中断言数量应该最小化也就是一个断言

    64370

    Android单元测试框架Robolectric3.0(二):数据篇

    (2)这不是QA人员该做? (3)需求天天变,功能都来不及完成了,还要同时维护代码和UT,四不四傻啊? (4)我要怎么写UT(特别是Android单元测试)?...这个话题太老生常谈了,配备有价值、高覆盖率单元测试可解决此问题。 (4)当你写Android代码(比如网络请求和DB操作)时候,如何测试?...这种做法不仅仅可以写UT过程中使用,开发过程中也可以使用,当服务端接口开发滞后于客户端进度时,可以先约定好数据格式,客户端采用模拟网络请求方式进行开发,此时两个端可以做到不互相依赖。...这里我列举一个场景,并进行相应单元测试:一个Activity中有个ListView,经过网络请求后,异步回调函数里加载ListView数据,点击每一个item后,吐司其对应标题。 ? ?...另外有一点要注意,当我们测试多个test时,会抛出一个类似于这样异常: java.lang.RuntimeException: java.lang.IllegalStateException:

    1.3K20

    vue中关于测试介绍

    简而言之,它从一个用户角度出发,认为整个系统都是黑箱,只有UI会暴露给用户 二、单元测试(Unit Test): 测试驱动开发(TDD: Test-Driven Development), 单元测试用来对一个模块...Vue中单元测试中有( Jest +Karma+ Mocha(Chai) ) Karma: Karma一 个基于Node.jsJavaScript测试执行过程管理工具( Test Runner)...需要它原因在于,你代码可能设计浏览器端执行,node环境下测试可能有些bug暴露不出来;另外,浏览器有兼容问题, karma提供了手段让你代码自动多个浏览器( chrome,firefox...如果你代码只会运行在node端,那么你不需要用karma。 Mocha mocha(摩卡)一个测试框架,vue-cli中配合。...with at of same Jest (一般使用这个,请仔细阅读) 官方提供单元测试模块@vue/test-utils,它使用Jest风格expect断言,具体示例如下: // 挂载这个组件

    97910

    .NET单元测试艺术-3.测试代码

    开篇:上一篇我们学习单元测试和核心技术:存根、模拟对象和隔离框架,它们我们进行高质量单元测试技术基础。本篇会集中管理和组织单元测试技术,以及如何确保真实项目中进行高质量单元测试。...如果单元测试中包含了下列语句就是包含了不应该有的逻辑: switch、if或else语句; foreach、for或while循环;   这种做法不值得推荐,因为这样测试可读性较差,也比较脆弱。...通常来说,一个单元测试应该是一系列方法调用和断言,但是不包含控制流程语句,甚至不应该将断言语句放在try-catch中。   ...(3)只测试一个关注点   如果我们单元测试多个对象进行了断言,那么这个测试有可能测试了多个关注点。一个单元测试中验证多个关注点会使得事情变得复杂,却没有什么价值。...如果没有回失败测试,可能就不会发现这些错误。 2.2 编写可维护性测试   可维护性大多数开发者在编写单元测试时面对核心问题之一。

    53930

    研效优化实践:聊聊单元测试那些事儿

    最开始,我们先看看大家认为单元测试是什么: 计算机编程中,单元测试一种软件测试方法,通过该方法对源代码各个单元(一个或多个计算机程序模块集合以及相关控制数据、使用过程和操作过程)进行测试以确定它们是否符合使用要求...在这个一句话定义里,有四个核心要素: 角色:开发同学 单元测试开发同学工作一部分,而不是测试同学工作内容。 阶段:编码阶段 单元测试开发编码阶段进行,而不是转测试之后才开始。...大部分情况下,我们自己给自己写函数做单元测试,当运用黑盒测试思路时,要 假装 被测函数别人写。 覆盖 单元测试中,覆盖率一个常用评估指标。 所谓覆盖,可以简单理解为 “被执行过”。...用例设计 设计单元测试用例中有很多方法:等价类划分、边界值分析、路径测试…… 在实践中,我们可以设计覆盖 正常流程 & 异常流程 两大类用例: 正常流程通过输入合法 典型数据、边界值 看基本功能是否正确实现...小经验分享 三条准则 单元测试必须经常跑 错误做法:为了完成 KPI 写了一堆测试,跑一次就不管了 正确做法:持续集成,自动化运行 从增量到存量,从主要到次要 从覆盖新模块、新功能做起,单元测试先跑起来再说

    94631

    单元测试-一份如何写好单元测试参考

    开始 首先,单元测试十分重要,试想如果没有单元测试,那么如何保证代码能够正常运行呢?...而对于测试数据一直变,并且测试数据量比较大时候可以使用测试数据外部化将数据放在测试用例外部进行统一管理。 什么数据外部化?...每个测试方法对被测试方法功能断言不宜过多,如果一个方法需要多个断言进行测试,我们可以进行大致分类,将其分不到两个测试方法中,这样可以细粒度进行测试。 8....注意测试代码覆盖率 一个设计好单元测试,其代码测试覆盖率也是很高,并不要求100% 测试代码覆盖率,但是高覆盖率代码包含未检测到错误几率要低,因为其更多源代码测试过程中被执行。...还有就是一些其他注意点了,比如 不要使用print语句去输出测试结果人工判断是否正确,要使用断言 一些不好理解测试最好在方法上面写明注释,便于后期理解与维护 使用框架进行单元测试,比如Junit5如果其中断言支持不满足你需求也可以使用

    2.1K20

    代码优化技巧·代码编写好习惯·代码规范

    循环内不要不断创建对象引用 例如: for (int i = 1; i <= count; i++) { Object obj = new Object(); } 这种做法会导致内存中有...推荐以后写并发时候复习一遍 代码规范 注释 不要给不好名字加注释,一个好名字比好注释更重要 不要“拐杖注释”,好代码 > 坏代码 + 好注释 文件/类级别使用全局注释来解释所有部分如何工作...某个公共函数调用私有函数紧随其后 最理想参数零参数,最长不要超过三个入参,尽量不要输出参数 如果函数传入三个及以上参数最好将其抽象为类 标识参数十分丑陋,向函数传入布尔值用于区分不同业务做法很丑陋...,已便判断错误来源与处所 不要将系统错误归咎于偶然事件 并发 分离并发相关代码与其它代码 严格限制对可能被共享数据访问 避免使用一个共享对象多个同步方法 保持同步区域微小,尽可能少设计临界区 单元测试...,比如 Test _ 测试代码与生产代码一样重要 如果测试代码不能保证整洁,你就会很快失去他们 每个测试一个断言,单个测试中断言数量应该最小化也就是一个断言 FIRST原则 快速 Fast 独立

    1.2K10
    领券