开发者社区

文档建议反馈控制台

最新优惠活动

文章/答案/技术大牛

发布

让单元测试在循环中运行是不是一种坏做法？

让单元测试在循环中运行是一种不推荐的做法。单元测试是用于验证代码的最小可测试单元的行为是否符合预期的方法。循环中运行单元测试可能会导致以下问题：

效率低下：循环中运行单元测试会导致测试用例的重复执行，增加了测试的执行时间。特别是在大规模的循环中，测试执行时间会显著增加，影响开发效率。
不可控性：循环中运行单元测试可能导致测试结果的不可预测性。循环中的每次迭代都可能受到前一次迭代的影响，使得测试结果不稳定。这样的测试结果难以重现和调试，给问题的定位和修复带来困难。
测试用例设计不合理：循环中运行单元测试可能暗示着测试用例的设计存在问题。单元测试应该是独立的、可重复的，不应该依赖于外部环境或其他测试用例的执行结果。如果需要在循环中运行单元测试，可能意味着测试用例的设计需要重新审视和优化。

推荐的做法是将单元测试设计为独立的、可重复的测试用例，并在适当的时机执行。可以使用自动化测试框架和工具来管理和执行单元测试，例如Junit、PHPUnit等。在持续集成和持续交付的流程中，可以将单元测试集成到自动化构建和部署流程中，确保代码的质量和稳定性。

腾讯云相关产品和产品介绍链接地址：

云开发（https://cloud.tencent.com/product/tcb）：提供一站式后端云服务，包括云函数、云数据库、云存储等，方便开发者快速构建和部署应用。
云服务器（https://cloud.tencent.com/product/cvm）：提供可扩展的云服务器实例，支持多种操作系统和应用场景，满足不同规模和需求的业务。
云数据库 MySQL 版（https://cloud.tencent.com/product/cdb_mysql）：提供高性能、高可用的云数据库服务，支持自动备份、容灾和监控等功能，适用于各种应用场景。
人工智能平台（https://cloud.tencent.com/product/ai）：提供丰富的人工智能服务和工具，包括图像识别、语音识别、自然语言处理等，帮助开发者构建智能化应用。
物联网开发平台（https://cloud.tencent.com/product/iotexplorer）：提供全面的物联网解决方案，包括设备接入、数据管理、远程控制等功能，支持快速开发和部署物联网应用。

请注意，以上仅为腾讯云的相关产品示例，其他云计算品牌商也提供类似的产品和服务。

相关搜索:在Project Server中运行更新脚本是不是一种坏做法在Go中为IO操作添加helper是不是一种坏做法？在单元测试中将预期结果建立在实际结果的基础上是不是一种坏做法？在微服务REST api调用中返回对象列表是不是一种坏做法？在c++中返回指向值类型的指针是不是一种坏做法在活动打开时每隔1秒循环一次线程是不是一种坏做法？让Jenkins Docker容器在Kubernetes集群内部处理CI/CD是不是一种糟糕的做法？在并行模式下使用同一事务运行多个查询是不是一种糟糕的做法？腾讯云新一代数据库腾讯云新人域名注册

相关搜索:

页面内容是否对你有帮助？

有帮助

没帮助

相关·内容

Python数据容器：集合

前言在 Python 中，数据容器是组织和管理数据的重要工具，集合作为其中一种基本的数据结构，具有独特的特性和广泛的应用。本章详细介绍了集合的定义、常用操作以及遍历方法。...元素2，元素3，元素4，…}定义空元组：变量名称 =set()②特点：可容纳多个数据可容纳不同类型的数据（混装）可修改（增加或删除元素等）数据是无序存储的（不支持下标索引）不允许重复数据存在支持for循坏...，不支持while循坏# 定义集合my_set={"A","B","C","B","A"}# 定义一个空集合my_set_empty=set()print(f"my_set的内容为{my_set}，类型是...for循坏遍历:# 集合的遍历# 集合不支持下标索引，所以不能用while循坏，可用for循坏set1={1,2,3}for element in set1: print(f"集合的元素有{element..., 'best']# 定义一个空集合my_set=set()# 通过for循坏遍历列表for element in my_list: # 在for循坏中将列表元素添加至集合 my_set.add

863 1

C语言中循环语句总结

while循坏: for循环: while和for循环的对比: 区别:for 和 while 在实现循环的过程中都有初始化、判断、调整这三个部分，但是 for 循环的三个部分⾮常集中，便于代码的维护...main() { int i = 1; for(i=1; i<=10; i++) { if(i == 5) break; printf("%d ", i); } return 0; } 运行结果...: continue:跳过本次循.环中 continue 后的代码，直接去到循环的调整部分。...; i++) { if(i == 5) continue;//这⾥continue跳过了后边的打印，来到了i++的调整部分 printf("%d ", i); } return 0; } 运行结果...: 对比for循环和while循环中continue对代码的运行影响: 分析代码可以知道它们修改条件的位置不同对于while循环的修改条件在continue后面所以当i=5时,他没法继续修改,而是陷入

1271 0

揪出代码的坏味道

如果你忘了在某个地方进行修改，或者对不同副本进行了不同的修改，程序可能就会出错。重复代码长期维护来说是一种噩梦。...3、注释掉的代码和死代码注释过的代码和死代码都是代码的坏味道，因为它们会形成误导，让程序员认为这些代码是程序的可执行部分。...4、打印调试打印调试是指在程序中临时调用print()显示变量的值，然后重新运行程序的做法。很多人误认为打印调试快速简单，但实际上为了获得用以修复错误的信息，通常需要多次重复运行程序。...优化坏味道的方法 1、重复代码解决重复代码的方法是去重，简单地说，通过把代码放在一个函数或者循环中，使其在代码中只出现一次。 2、魔数解决方法是使用常量替代魔数。...6、嵌套列表解析式最好的办法是把列表解析式扩展到一个或者多个for循环中。最后，我们要正视代码的坏味道，有些代码的坏味道根本不是真正的坏味道。

4952 0

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

一、注释不要给不好的名字加注释，一个好的名字比好的注释更重要；不要“拐杖注释”，好代码 > 坏代码 + 好注释；在文件/类级别使用全局注释来解释所有部分如何工作；一定要给常量加注释；团队统一定义标记...：不恰当的信息；废弃的注释；冗余注释；糟糕的注释；注释掉的代码；唯一真正好的注释是你想办法不去写的注释：不要有循规式注释，比如setter/getter注释；不要添加日志式注释，比如修改时间等信息...某个公共函数调用的私有函数紧随其后；最理想的参数是零参数，最长不要超过三个入参，尽量不要输出参数：如果函数传入三个及以上参数最好将其抽象为类；标识参数十分丑陋，向函数传入布尔值用于区分不同业务的做法很丑陋...；经常性地通读标准库的整个API，保持对他们的熟悉程度；简单设计：运行所有测试；不可重复；表达了程序员的意图；尽可能减少类和方法的数量；以上规则按重要程度排列；无论是设计系统或者单独模块...，别忘了使用大概可工作的最简单方案；整洁的代码只提供一种而非多种做一件事的途径，他只有尽量少的依赖。

73921 18

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

(2)当你写单元测试的时候，是不是发现很多代码无法测试？...(3)是不是对重构没信心？这个话题太老生常谈了，配备有价值的、高覆盖率的单元测试可解决此问题。 (4)当你在写Android代码（比如网络请求和DB操作）的时候，是如何测试的？...关于第二个问题，己所不欲勿施于人我始终觉得让QA写UT，是一种傻叉的行为。单元测试是一种白盒测试，本来就是开发分内之事，难道让QA去阅读你恶心的充满坏味道的代码，然后硬着头皮写出UT？...这种做法不仅仅可以在写UT的过程中使用，在开发过程中也可以使用，当服务端的接口开发滞后于客户端的进度时，可以先约定好数据格式，客户端采用模拟网络请求的方式进行开发，此时两个端可以做到不互相依赖。...网络请求的异步回调如何进行测试关于网络请求之后的回调函数如何测试，笔者暂时也没有什么自己觉得满意的解决方案，这里提供一种做法，权当抛砖引玉，希望有此经验的人提供更多的思路。

1.3K2 0

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

一、注释不要给不好的名字加注释，一个好的名字比好的注释更重要；不要“拐杖注释”，好代码 > 坏代码 + 好注释；在文件/类级别使用全局注释来解释所有部分如何工作；一定要给常量加注释；团队统一定义标记...：不恰当的信息；废弃的注释；冗余注释；糟糕的注释；注释掉的代码；唯一真正好的注释是你想办法不去写的注释：不要有循规式注释，比如setter/getter注释；不要添加日志式注释，比如修改时间等信息...某个公共函数调用的私有函数紧随其后；最理想的参数是零参数，最长不要超过三个入参，尽量不要输出参数：如果函数传入三个及以上参数最好将其抽象为类；标识参数十分丑陋，向函数传入布尔值用于区分不同业务的做法很丑陋...；经常性地通读标准库的整个API，保持对他们的熟悉程度；简单设计：运行所有测试；不可重复；表达了程序员的意图；尽可能减少类和方法的数量；以上规则按重要程度排列；无论是设计系统或者单独模块...，别忘了使用大概可工作的最简单方案；整洁的代码只提供一种而非多种做一件事的途径，他只有尽量少的依赖。

5322 0

Python应用之求100以内的奇数和

在数学中，我们需要用到很多求和的办法，比如说求1至100的和，还有100以内的所有偶数和和所有奇数和，如果我们慢慢地计算是不是很浪费时间，还容易出错。...代码运行效果：方法二：for循坏 count = 0 for number in range(100): if number % 2 == 0: continue...：方法三：while循坏 count = 0 number = 1 while number < 100: count += number number += 2 print...: count = sum(x + 2) return x + count print(sum(1)) 先看下什么是递归：递归（Recursion）递归是一种解决问题的思路...，其精髓在于将问题分解为规模更小的相同问题，直到问题规模小到可以用非常简单直接的方式来解决，其算法方面的明显特征就是：在算法流程中调用自身。

2.4K2 0

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

一、注释不要给不好的名字加注释，一个好的名字比好的注释更重要；不要“拐杖注释”，好代码 > 坏代码 + 好注释；在文件/类级别使用全局注释来解释所有部分如何工作；一定要给常量加注释；团队统一定义标记...：不恰当的信息；废弃的注释；冗余注释；糟糕的注释；注释掉的代码；唯一真正好的注释是你想办法不去写的注释：不要有循规式注释，比如setter/getter注释；不要添加日志式注释，比如修改时间等信息...某个公共函数调用的私有函数紧随其后；最理想的参数是零参数，最长不要超过三个入参，尽量不要输出参数：如果函数传入三个及以上参数最好将其抽象为类；标识参数十分丑陋，向函数传入布尔值用于区分不同业务的做法很丑陋...；经常性地通读标准库的整个API，保持对他们的熟悉程度；简单设计：运行所有测试；不可重复；表达了程序员的意图；尽可能减少类和方法的数量；以上规则按重要程度排列；无论是设计系统或者单独模块...，别忘了使用大概可工作的最简单方案；整洁的代码只提供一种而非多种做一件事的途径，他只有尽量少的依赖。

6437 0

JAVA语言程序设计（一）04747

标识符可以包含英文、0-9数字、$、下划线不能以数字开头不能有关键字建议命名方式首字母大写、后面每个单词的首字母都大写首字母小写，后面每个单词的首字母都大写方法名：同变量名常量常量：在程序运行期间固定不变的量...自增自减运算符：++、– 基本含义：让一个变量涨一个数字1，或者让一个变量降一个数字1....，一般可以分成四部分初始化语句：在循坏开始最初执行，而且只做唯一一次条件判断：如果成立，则循坏继续，不成立循坏退出循坏体：重复做的事情内容，若干行语句步进语句：每次循坏之后要进行的扫尾工作，每次循坏结束都要这样...for循坏 while循坏标准格式 while(条件判断){ 循坏体 } 先执行初始表达式，看布尔表达式，满足就执行循坏体跟步进表达式 do while 初始化语句...do{ 循坏体 }while(条件判断); 求100里的偶数和装了个notpad++感觉还可以的，写中文终于不乱码了三大循坏的区别循坏控制 break语句

5.1K2 0

Android为什么不能在子线程更新UI

如果不做这个校验，是不是我也可以正常在子线程更新UI 但是google为什么要这样去设计呢 ViewRootImp是在onActivityCreated方法后面创建的吗为什么一定需要checkThread...为什么还需要开启消息循坏使用子线程更新UI有实际应用场景吗 Android为什么不能在子线程更新UI？ // Android中为什么子线程不能更新UI？...则会抛出异常如果不做这个校验，是不是我也可以正常在子线程更新UI // 如果不做这个校验，是不是我也可以正常在子线程更新UI？...为什么还需要开启消息循坏 // 保证上述条件1成立，不就可以避免checkThread时候抛出异常了吗？为什么还需要开启消息循坏？...条件 2 可以让更新的 UI 效果呈现出来。

1.5K2 0

基础算法系列之排序算法-2.冒泡排序

它是一种简单的排序算法。 ---- 冒泡排序的算法思想通过两两比较相邻的数，如果发现这两个数不满足次序要求使，则将这两个数进行交换，从而实现"冒泡"。...---- 冒泡排序的实现过程从序列的最后一个数开始，不断地将小的数往上冒，通过n-1(假设有n个数)次循坏之后，这组序列就成了一个有序的序列。...---- 代码实现 public static void bubbleSort (int[] a) { for(int i =0;i<a.length-1;i++) //控制循坏的次数为...j] = a[j-1]+a[j]-(a[j-1]=a[j]); //将两个数进行交换，也可以通过中间值temp进行交换 } } } 运行下面代码...public static void bubbleSort(int[] a ) { for(int i=0;i<a.length-1;i++) //控制循坏的次数为n-1次

4163 0

『Go 语言学习专栏』-- 第十一期

好，本节的主题是：单元测试。测试其实分很多种，就我在企业中的认识，一般称为测试工程师，从事的应该是所谓的集成测试(或者说是 AC测试（Acceptance Criteria，验收准则）)。...我讲其中的一种吧。比如微服务领域，大多数服务其实是RESTful API 的形式。如何进行功能测试？...即你提交代码，自动会触发UT, 运行程序内的单元测试，单元测试之后有一定的质量统计，比如覆盖率，一般的大厂的代码覆盖了阈值是90%, 即提交代码，UT 运行之后，代码的覆盖率达到 90% 才可以合入。...编写一个测试，再写函数，直到测试通过，如此循坏。...(当然实际上测试驱动开发，真正实施还是略微有点困难，一般的做法都是开发、测试，而不是测试、开发、测试、开发) 一般的初学者，是不太会关注测试，在没有进入职场之前，我甚至完全没关注测试，直到走入职场...

5463 0

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

一、注释不要给不好的名字加注释，一个好的名字比好的注释更重要；不要“拐杖注释”，好代码 > 坏代码 + 好注释；在文件/类级别使用全局注释来解释所有部分如何工作；一定要给常量加注释；团队统一定义标记...：不恰当的信息；废弃的注释；冗余注释；糟糕的注释；注释掉的代码；唯一真正好的注释是你想办法不去写的注释：不要有循规式注释，比如setter/getter注释；不要添加日志式注释，比如修改时间等信息...某个公共函数调用的私有函数紧随其后；最理想的参数是零参数，最长不要超过三个入参，尽量不要输出参数：如果函数传入三个及以上参数最好将其抽象为类；标识参数十分丑陋，向函数传入布尔值用于区分不同业务的做法很丑陋...；经常性地通读标准库的整个API，保持对他们的熟悉程度；简单设计：运行所有测试；不可重复；表达了程序员的意图；尽可能减少类和方法的数量；以上规则按重要程度排列；无论是设计系统或者单独模块...，别忘了使用大概可工作的最简单方案；整洁的代码只提供一种而非多种做一件事的途径，他只有尽量少的依赖。

7231 0

C语言代码优化的一些经验及小技巧（三）

如果循环迭代次数只有几次，那么可以完全展开循环，以便消除循坏带来的负担。...使用位运算替代四则运算在许多古老的微处理器上，位运算比加减运算略快，通常位运算比乘除法运算要快很多。在现代架构中，位运算的运算速度通常与加法运算相同，但仍然快于乘法运算。...K&R C设计者认为复合赋值符可以让程序员把代码写得更清楚些。另外，编译器可以产生更为紧凑的代码。...在第一种形式种，由于编译器无从知道f函数是否具有副作用，所以它必须两次计算数组a的下标表达式的值。而在第二种形式中，下标表达式只需计算一次，所以第二种形式效率更高。...并且，从书写的角度看，第一种形式的下标表达式需要书写两次，而第二种形式只需书写一次。尽量使循环体内的工作量达到最小化循环中，随着循环次数的增加，会加大对系统资源的消耗。

2.2K2 1

The clean coder 读书笔记

要用这些自动化单元测试去测多少代码呢？还要说吗？全部！全部都要测这一种方法，就是TDD，来规避这个问题。作者是TDD的践行者如果连所有代码是否都可以正常运行都不知道，还算什么专业人士？...聪明的开发者们宁可在出了问题花大量的精力去一步步调试，也不愿花一点点的时间去写单元测试，执行TDD。...曾经在读云风博客时，发现一段有共鸣的话反感围绕着调试的开发方式，也是不断的在测试，试错，纠正的循环中奔波，好的程序员应该努力的在编写的过程中，在头脑中排错，在预感到坏味道时，就赶紧重写，而坏味道就是代码陷入了复杂度太高的境地...对付复杂度最好的武器是简化代码在遇到bug时，应该仔细浏览代码，设想各种出错的可能。而不是将错误代码运行起来，查看运行中的状态变化这段话中不赞成的解决问题方式，其实是很多开发人员普遍具备的。...这是时间管理时提到的，李笑来也讲，注意力是你最宝贵的财富时间在本质上不属于你，你只能试着与它做朋友，让它为你所用。你的注意力才是你所拥有最重要、最宝贵的资源。你可以自己作主，要把它放在“成长”上。

3592 0

豆瓣 9.1！二刷了这本经典，YYDS

学习重构必看的一本神书《重构：改善代码既有设计》从两个角度给出了重构的定义：重构（名词）：对软件内部结构的一种调整，目的是在不改变软件可观察行为的前提下，提高其可理解性，降低其修改成本。...让代码更容易理解：通过添加注释、命名规范、逻辑优化等手段可以让我们的代码更容易被理解；避免代码腐化：通过重构干掉坏味道代码；加深对代码的理解：重构代码的过程会加深你对某部分代码的理解；发现潜在...开发一个新功能之后&之前在开发一个新功能之后，我们应该回过头看看是不是有可以改进的地方。在添加一个新功能之前，我们可以思考一下自己是否可以重构代码以让新功能的开发更容易。...我们在阅读理解代码的时候，如果发现一些坏味道的话，我们就可以对其进行重构。...另外，多提一句：持续集成也要依赖单元测试，当持续集成服务自动构建新代码之后，会自动运行单元测试来发现代码错误。怎样才能算单元测试呢？网上的定义很多，很抽象，很容易把人给看迷糊了。

3872 0

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

推荐以后写并发的时候在复习一遍代码规范注释不要给不好的名字加注释，一个好的名字比好的注释更重要不要“拐杖注释”，好代码 > 坏代码 + 好注释在文件/类级别使用全局注释来解释所有部分如何工作...，而非明显的细节不要在代码中加入代码的著作信息，git可以干的事情不要交给代码源代码中的html注释是一种厌物, 增加阅读难度注释一定要描述离它最近的代码注释一定要与代码对应公共api需要添加注释...，其它代码谨慎使用注释典型的烂注释不恰当的信息废弃的注释冗余注释糟糕的注释注释掉的代码唯一真正好的注释是你想办法不去写的注释不要有循规式注释，比如setter/getter注释...经常性地通读标准库的整个API，保持对他们的熟悉程度简单设计运行所有测试不可重复表达了程序员的意图尽可能减少类和方法的数量以上规则按重要程度排列无论是设计系统或者单独模块，别忘了使用大概可工作的最简单方案...整洁的代码只提供一种而非多种做一件事的途径，他只有尽量少的依赖。

1.2K1 0

码农，你真的了解TDD和BDD吗？

因为在很多单元测试框架运行测试的过程中，测试不过时会用红色展示测试结果，而通过时则采用绿色进行展示，这已经成了单元测试框架约定俗成的规则。...然而，这种想问题的方式会让人忽略新增代码可能带来的坏味道（Code Smell），坏味道会让代码逐渐腐坏，这是一个工程问题，也就是会有长期影响的问题。...对很多人来说，TDD 是一种难以接受的做法，抛开理念上的差异，更重要的原因是，写测试无从下手。很多时候写不出测试，主要是面对的需求太大了。...单元测试框架写测试的方式更多的是面向具体的实现，这种做法的层次是很低的，BDD 希望把这个思考的层次拉高。拉到什么程度呢？...如果登录方式有所调整，用户输完用户名密码自动登录，不需要点击，那这个用例是不是需要改呢？下面我换了一种方式描述，你再感受一下。

8741 0

单元测试与重构

“重构”，因为刚刚只是让代码跑起来了，设计上还有可改之处，新增代码往往存在很多“坏味道”，而重构则是消除坏味道的手段，一旦有了测试，就可以大胆的进行重构，因为任何错误都可以很容易的被捕捉到。...如果把“先写代码，后补测试”转换成：先写测试，写代码是为了让测试通过，写出的代码天然具备可测性，是不是就变得简单了呢？...在实际开发工作中，经常能见到长达100行及以上的函数/方法，这种代码绝大部分开发者会说不具备可测性。如果写代码时时刻想着可测性，是为了让测试通过，开发者再写这么长行数的代码都难。...一种测试常见的坏味道是没有断言！这种测试就从来没失败过，一看代码竟然是print，这种测试最多也就能证明你曾经debug过这段代码。...结合到日常开发工作中，可以在以下几个节点进行：添加功能时一并重构修复BUG时一并重构代码评审时一并重构 是不是有些情况，也不适合重构？

7974 0

一个完整的TDD演练案例（二）

一种做法是获取Answer的属性，然后再进行验证。那么，为了测试的验证而暴露这些属性，是否适合？要完成对答案正确性的验证，直接暴露答案的属性是不妥当的，至少目前没有获取答案属性的需求。...毕竟，这种对答案正确性的校验，也可以说是业务逻辑的一种。说明：在开始编写“检查输入是否合法”任务时，你会发现，这里所谓多余的验证，就会派上用场。...一种是传统的在测试代码中通过编写try... catch结合fail()方法进行验证。这种方法带来的问题是验证逻辑太繁琐。第二种方法是利用@Test的expected方法，通过指定异常类型值来验证。...随机数带来了不确定性，它可能偶然地让测试通过了。也许，运行测试100次，前面的99次都通过了，最后一次失败，仍然视为失败。生成随机数自然是调用Java的JDK。...在单元测试环节中，倘若我们要测试的单元需要调用别的API，则在这个测试中，我们可以假定这个API是正确的。我们对Java JDK的正确性自然信心十足。那么，为何我们还要考虑测试的随机失败？

8103 0

点击加载更多

扫码

添加站长进交流群

领取专属 10元无门槛券

手把手带您无忧上云

扫码加入开发者社群

相关资讯

热门标签

活动推荐

运营活动

活动名称

广告关闭