首页
学习
活动
专区
工具
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

PDF是Portable 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轴比例缩放页面

89110

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....单元测试必须使用断言;另外除了类型检查和单元测试外,断言还提供了一种确定各种特性是否在程序中得到维护的极好的方法;

3K00
  • 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

    c++代码整洁之道

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

    1.1K10

    Selenium2+python自动化51-unittest简介

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

    80960

    如何写好 GO 语言单元测试

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

    2.1K20

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

    前言 关于单元测试的定义和好处可以借用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.

    35320

    码农,你真的了解TDD和BDD吗?

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

    98510

    实例入门 Vue.js 单元测试

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

    2.9K20

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

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

    53620

    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 断言方法。

    49830

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

    笔者推荐三本经典的书籍《代码整洁之道 》、《编写可读代码的艺术》、《重构:改善既有代码的设计》,下文重点将从注释、命名、方法、异常、单元测试等多个方面总结了一些代码整洁最佳实践,大部分是笔者总结于以上三本书中的精华...一、注释 不要给不好的名字加注释,一个好的名字比好的注释更重要; 不要“拐杖注释”,好代码 > 坏代码 + 好注释; 在文件/类级别使用全局注释来解释所有部分如何工作; 一定要给常量加注释; 团队统一定义标记...; 某个公共函数调用的私有函数紧随其后; 最理想的参数是零参数,最长不要超过三个入参,尽量不要输出参数: 如果函数传入三个及以上参数最好将其抽象为类; 标识参数十分丑陋,向函数传入布尔值用于区分不同业务的做法很丑陋...,尽可能少设计临界区; 六、单元测试 不要怕单元测试的方法名字太长或者繁琐,测试函数的名称就像注释; 不要追求太高的测试覆盖率,测试代码前面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

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

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

    54330

    vue中关于测试的介绍

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

    98610

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

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

    1.2K10

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

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

    2.1K20

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

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

    98631
    领券