随手google到gigix的blog,看了一些他的观点和若干人等的相关评论,有些觉得颇有道理,摘录如下。
看“测试驱动开发”这个名字,首先应该明确:与它对应的是“文档驱动开发”。它是一种开发过程,这里的测试是一个设计问题,而不是QA问题。在没有 TDD之前,“正统的”开发过程要求有设计文档:高层设计描述一个模块“做什么事”,详细设计描述一个模块“如何做这些事”。软件工程课讲得清楚,只有源代码的软件不能算软件,因为它不可理解、不可维护;源代码加上文档,才算是程序员完整地交付了自己的工作。要做任何一件事之前,你必须首先清楚地知道自己要做什么(以及不要做什么),否则那就是crack,不是在从事职业的软件开发。
但这种文档有几个致命的缺陷。第一,自然语言的描述容易产生歧义;第二,不能自动化地验证;第三,不能保证文档与程序同步。测试驱动开发正是为了解决这些问题而产生的。在编写一段代码之前你所写的测试,不是为了确保这段代码不出错,而是为了描述你想要做的事情。当你拥有这个测试之后,持续集成会始终确保你的代码恰好是做了你想要做的事情。测试驱动开发是一种设计方法,它清晰无二义地描述你的设计,并保证设计与实现一致。
所以几个典型的问题就可以很清楚地找到答案。单元测试要不要是白盒的?要。因为你是在描述如何实现这个模块,而不是验证它的输入输出正确性。单元测试要不要把每个模块放到真实的事务或者并发环境下测试?不要。因为你只是描述当前模块的实现,真实环境下的正确性由集成测试和QA来保证。为什么模块内部实现的变化要同时导致测试变化?因为你的思路、你的设计变化了,你应该有一个文档描述这件事情。
(如何用unit test测试私有方法)...重点在于,你不应该有任何方法是从一开始设计出来就是private的,因为你的每段程序都应该在单元测试的驱动之下产生,而测试是不可能驱动出来一个private方法的。那么private方法从哪里来?只能从重构而来。所以答案是:private方法是不需要测试的,因为它是重构的产物,而重构是不改变程序可观察之行为的。既然行为不改变,测试自然也不需要有任何改变,所以不需要针对private方法建立任何新的测试。
但是,如果private方法确实出现问题了怎么办?如果你确实希望用测试来弄清一个private方法里面到底发生了什么,该怎么办?
答案是:如果一个private方法复杂到你不能一眼看清它,那它就太复杂了,你应该把它重构成为一个独立的class,然后针对这个class来建立单元测试
关于这个对private方法的单元测试,记得两年前我在bbs上跟别人有过讨论,当时对单元测试的理解太粗浅了。现在我的理解跟gigix基本上是一致的。嗯,虽然这一年多基本上没写过unit test-_- 但有些东西还是在不知不觉中进步的啊。就好像下棋一样,对棋的理解确实会随着时间的增加而逐渐提高,当然这种提高是很有限的,并且距离实战还有很大的距离,必须多进行一些实际的对局才能把这种提高转化成真正对自己下的棋所有帮助的东西,或者说必须和实战所结合起来。不然的话,所谓的提高就只会让你的棋漏洞百出,被对手打得落花流水。
遇到什么东西不由你选。要是程序员可以决定自己将要遇到什么东西,用汇编写写就可以了,还搞什么这个P那个P,结构化都用不着。
另外说句废话——o6z也许又要骂我,不过这话我觉得不能算和职业无关——我最讨厌程序员自以为是的批评什么“鬼东西”、“垃圾设计”。就是这些“垃圾设计”的“遗留系统”,运转着银行的绝大多数业务逻辑,创造着证券业信息化系统的绝大部分价值。没错,用2004年的眼光(甚至是1998年的眼光)来看,它们是腐烂代码,它们是垃圾设计。但我们自以为是的那些优秀设计,它们做了什么?它们不过是在运转一些边沿业务,提供几个漂亮的网站展示而已。说白了,这些东西才是可有可无的垃圾。可以运转的程序就是好的程序,正常运转了超过十年的程序是精彩绝伦的程序,不懂得敬畏这些程序的人,做不好企业级应用。
这段牢骚说的也有点道理。但我觉得,这并不是历史发展的趋势。将来恐怕还是那些“我们自以为是的那些优秀设计”的天下,即使它们现在看上去是“可有可无的垃圾”。那些“正常运转了超过十年”的“精彩绝伦的程序”,也许还将继续运转下去,但是这些程序所占的比重只会越来越少。就如同资本主义的工业化战胜了封建行会的手工作坊,就算有些天才的技术工人能够制造出高超的产品,质量比机器生产出来的东西要高得多,但这阻挡不了机器的社会化大生产成为潮流,而那些有着顶尖技法的天才,终究不会成为主流。软件的发展也会使进入的门槛越来越低,这时那些集中着天才智慧的程序的用武之地会越来越小,能够推动每个熟练工人生产力的提高才是更重要的东西。毕竟不可能每个人都是天才。
相关推荐
重构遗留系统的五大实战技巧与设计模式应用
在软件开发中,重构是提升代码质量的重要手段,尤其对于遗留系统而言更为关键。重构的核心原理是通过调整代码结构来改善设计,而不改变其外部行为。这种技术能显著提升系统的可维护性和扩展性,降低技术债务。在实际工程实践中,重构常应用于模块解耦、性能优化等场景。本文重点探讨了测试驱动开发(TDD)与Git分支策略在重构中的应用,通过建立自动化测试安全网和优化版本控制流程,可以有效降低重构风险。其中,设计模式的合理运用能解决常见的代码坏味道问题,如策略模式处理复杂条件逻辑,工厂模式管理对象创建过程。这些方法特别适合处理常
软件测试中测试桩和测试驱动的含义
所谓的测试桩,就是你负责测试的模块/方法所调用的,所以你需要模仿他们做一个返回值(假的,但符合设计)。 桩的英文是stub;是指一个软件模块的框架或特殊目标实现,主要用于开发和测试一个组件,该组件调用或依赖这个模块。桩模块:集成测试前要为被测模块编制一些模拟其下级模块功能的“替身”模块,以代替被测模块的接口,接受或传递被测模块的数据,这些专供测试用的“假”模块称为被测模块的桩模块。测试桩一般是
美团外卖 mtgsig 1.2 逆向工程与补环境实战指南
本文深入解析了美团外卖核心风控参数mtgsig 1.2的生成机制与逆向实战。通过拆解其复杂的JSON结构,揭示了设备指纹、环境信息加密等关键字段。重点阐述了在Node.js中模拟浏览器环境(补环境)的核心方法,包括DOM/BOM对象、本地存储及Canvas/WebGL等高级指纹的模拟技巧,为安全研究和合规自动化测试提供了一套完整的技术指南。
JE 追MM 经验书(大)
http://www.iteye.com/topic/454385?page=1 一、问题:追女孩的方法 sunfengcheng 近日 偶 同学给介绍一女友,经几日聊天后感觉还可以.但近日竟说我不真实,好假. PS1:我们相距千里之外 PS2:我说有时间去看他,但一直苦于没有时间. PS3:我说在七夕节为她寄送礼物,但她说礼物不重要,物质并不能表名爱不爱她!...
AlphaFold2算法详解
正文:https://www.nature.com/articles/s41586-021-03819-2 补充文件:https://static-content.springer.com/esm/art%3A10.1038%2Fs41586-021-03819-2/MediaObjects/41586_2021_3819_MOESM1_ESM.pdfhttps://static-content.springer.com/esm/art%3A10.1038%2Fs41586-021-03819-2/Med
浮点数加法器设计
一.设计内容及其要求 内容 根据浮点数的运算规则和IEEE754标准,实现浮点数的加法运算器。 要求: 浮点数格式:符号位1位,阶码8位,尾数23位 要求该实验能完整的体现浮点数的运算的五个步骤:对阶、尾数求和、规格化、舍入(要求使用对偶舍入)、溢出判断。 二.基本要素 浮点数 浮点数即实数,实数是所有有理数和无理数的集合。它之所以被称作浮点数,是因为小数点在数中的位置并不是固定的。一个浮点数值分为两部分存储:数值以及小数点在数值中的位置。 计算机中的浮点运算的计算结果一般是不确定的,一块芯片的浮点运算
敏捷质疑
Q: 为什么通过单元测试发现的 Bug 很少 ? A: 单元测试不是用来发现 Bug 的, 而是用来预防 Bug 的. 如果采用 TDD, 测试用例完成之时, 产品代码尚未编写, Bug更无从谈起. Q: 那是否写单元测试就能提高代码质量了 ? A: 关于这一点, 似乎有人不这么看, <<TDD Opinion: Quality Is a Function of Thought and...
使用网分对晶体ESR/L1/C1/C0进行测量计算
Use R&S Vector Network Analyzer test XTAL ESR/L1/C1/C0 測量方法:使用儀器的Port1端口,測量XTAL的S11,通過諧振的參數計算出ESR/L1/C1/C0的值。 實際晶體的等效模型:通常方便晶體分析,使用下圖(b)的等效模型,但實際測量發現晶體存在多個串聯諧振點,實際等效模型更接近(c)。 儀器測量到的S11,其中M...
以自动化测试撬动遗留系统
面对遗留系统,选择合适的测试策略,能让自动化测试的投入在一定时期内看到效果,并且建立可持续进行的机制。同为自动化测试,每种测试在面对遗留系统时遇到的挑战是不同的,起到的效果也不尽相同。 背景 我目前所服务的企业大部分系统是遗留系统,其中多数处于相对需求平稳阶段,即需求并不多,也没有大需求。但这些系统牵制了和需求所需人力不成比例的大量人力,从系统本身的原因看,有这么几点。 ● ...
PAM4信号测试实战:从眼图分析到误码率测量的技术演进
在高速数字系统设计中,信号完整性测试是确保数据传输可靠性的核心环节。其基本原理在于通过时域和频域分析,精确评估信号在传输过程中的质量衰减与失真。随着数据速率向56Gbps及以上演进,传统的NRZ编码面临带宽瓶颈,而PAM4调制技术通过在每个符号周期内承载更多比特信息,成为提升信道效率的关键路径。这项技术的工程价值在于,它允许在相同带宽下实现翻倍的数据吞吐量,这对于数据中心互联、PCIe 6.0及800G以太网等高速接口至关重要。然而,PAM4信号电平间距更小,对噪声和抖动极为敏感,导致其原始误码率显著升高,
C++高级数据结构算法 | 二叉树的四种遍历算法详解(递归与非递归实现)
二叉树遍历方法 、前序遍历算法 、中序遍历算法 、后序遍历算法 、层序遍历算法
场景驱动的 AI 体验设计:如何让智能 IDE 赋能遗留系统重写
作为 AutoDev 的核心开发,我们不仅在不断丰富 AutoDev 的功能以满足不同公司的定制需求,还在与各种团队进行持续交流。在处理遗留系统时,我们发现程序员们日常工作中需要面对大量使用过时技术、基础设施混乱的系统。在这个背景下,探索如何利用人工智能增强这些系统的演进成为一项极富挑战性的任务。毕竟,大佬们都说:所有的应用都要重写一遍。PS:当然了,大佬也在说:未来不会有应用~~。为什么场景驱动...
《中国电信运营商骨干网:历史、现状与未来演进》系列 第一篇:中国骨干网全景图:一级运营商与专用网络的演进
揭秘国家信息高速公路!一文读懂什么是骨干网,它如何支撑我们的数字生活,以及电信、联通、移动、广电等巨头如何构建这张“国家级动脉”。
读书笔记之测试驱动开发优点
当面对一个没有任何测试代码的遗留系统时,如果要想修改其中的程序结构或是新增代码,需要谨小慎微才行,因为这是一件风险极大的事情。尤其是大规模的改动,稍有不慎便会破坏原有代码的正确性,从而引入bug,而这种bug,也许只能通过后期的集成测试才能被发现。按照经典软件工程的理论,这种bug的修改成本,往往都是代价高昂的。始终以TDD方式进行软件开发的结果便是形成一整套可运行的测试用例集。这使得我们对
安路TangDynasty和FD和JTAG驱动器安装
安路FPGA产品矩阵包含SALPHOENIX高性能、SALEAGLE高性价比和SALELF低功耗三大系列,广泛应用于网络通信、消费电子等领域。配套的TangDynasty(TD)集成开发环境支持标准设计输入,提供完整优化流程与调试工具。简要介绍了TD 6.2.1版本的安装步骤。
RU DOS版、EFI版32bit/64bit BIOS常用工具
DOS版、EFI版的RU工具,可用来查看IO、MEM、PCI、SMBIOS等资源。亲测在EFI SHELL下可用。
70道测试驱动开发面试八股文(答案、分析和深入提问)整理
TDD是一种软件开发流程,先编写测试用例,再编写能通过测试的代码,最后进行代码重构。测试数据的处理对TDD流程的顺利进行至关重要。测试数据准备:在每个测试用例开始前,通过数据初始化、数据工厂、数据种子等方式准备所需的初始数据。测试数据清理:在每个测试用例结束后,利用后置清理、事务管理、模拟外部依赖等方法清理测试过程中产生的数据。确保独立性和可重复性:隔离测试环境,将测试数据和代码纳入版本控制,使用自动化测试框架执行测试用例。
复分析 阿尔福斯(Ahlfors) 第三版答案 英文
答案分为十章,有部分习题没有答案,全英文复分析阿尔福斯(Ahlfors) 第三版答案
遗留系统改造:逐步重构与接口适配的策略
分步重构将系统拆解为独立模块,优先改造高价值或高风险的组件。例如,将单体应用拆分为微服务,每次只迁移一个功能模块,通过持续集成验证稳定性。直接替换遗留系统成本高、风险大,而逐步重构与接口适配成为平衡效率与稳定性的关键策略。这一策略通过渐进式优化,既保留系统核心功能,又为技术升级铺平道路。例如,采用API网关统一管理请求转发和数据格式转换,避免因技术栈差异导致的数据孤岛。结合契约测试,确保接口适配层的输入输出符合预期。通过分步重构、接口适配和测试驱动三大策略,企业能以最小代价实现技术演进,最终完成平滑过渡。
Outlook Express 6 (OE6) for Win7/Win8/Win10
英文版 Outlook Express6.0, 兼容Win7/Win10/WinXP,解压就可用。
遗留系统不是让 AI 重写一遍:代码智能体驱动的行为保护式现代化
我参与过一次结算系统改造。代码库运行了十多年,核心模块混合了早期 Java、SQL 存储过程、定时脚本和少量后来补上的 Python 服务。团队最初给代码智能体的目标很直接:把一个 4200 行的账单模块拆成几个 FastAPI 服务,并补齐测试。模型在两天内生成了结构清晰的新工程,接口文档、类型提示和容器配置看起来都比旧系统规整。问题出现在第一次历史账单回放。新服务按照文档计算的金额完全正确,却漏掉了旧系统中一个没有写进需求的规则:月底最后一个工作日生成的跨区订单,会把小数尾差归入主结算主体。
TDD,Dont DDT
一直有个疑问,对于遗留系统,我们该如何TDD ? 我个人比较认同TDD是一种设计方法,不能代替真正意义上的测试。是帮助我们设计自己代码的一种方法。对于遗留系统,面对一堆需求文档,面对一陀陀已经难 以继续维护的陈旧代码,你的心是否哇凉哇凉的 ?做为一个使用Rails的开发人员,难道你要把这些代码翻译为Ruby代码吗 ? 答案当然是不! 很多时候,我们虽然很清楚要TDD,但是很多时...
当传统遇见现代——遗留系统的测试困境与机遇
本文探讨了遗留系统自动化测试的渐进式策略。针对文档缺失、技术债等挑战,提出分阶段实施方案:首先评估系统风险并选择合适工具;其次通过试点验证可行性;然后分层构建测试体系(单元/API/UI测试);最后持续优化维护。强调应优先保障核心业务稳定,逐步替换手动测试,并规避过度自动化等风险。通过这一转型,测试角色将从被动缺陷发现转变为主动质量赋能,实现从"救火"到"防火"的范式升级。
遗留系统改造微服务
随着企业规模的扩大以及微服务技术的逐渐成熟,更多企业开始尝试使用微服务的方式进行系统开发。但是技术的转型并不能一蹴而就,因为一般技术部门要保持需求的开发进度,所以研发并不能停下需求研发,而单单做技术的转型。这就造成遗留系统改造微服务比新系统直接使用微服务方式开发更复杂,在这个复杂的过程,要寻求业务与技术上的平衡。 系统改造原由 1、新开发人员维护系统存在大量知识盲区,一些业务规则...
开发中测试与细节
这两天在开发一个文件上传功能,如果在合理的架构下,或者适应的场合,对于java,这个功能简直任何人都可以完成的! 可是偏偏是我们前辈遗留下来的牛逼框架下开发,我一度认为都是无法达成这个任务! 花了两三天时间,还有在同事的协助下,才搞定了技术问题!唉,真的是自我最大的嘲讽! 回想下这个过程,有几点感受特别的深刻! 一:测试 由于平时一般都比较简单,所以测...
「勿忘初心」TDD,Dont DDT
偶尔翻到自己五年前写的关于TDD的文章,又看一遍, 感觉当时的自己是走在正确的路上。但是这么多年过去了,BDD也在流行,自己却没有一直沿着这条路走下去,为什么? 老文重拾,感慨良多。这个过程是我当时在用Ruby改造一个php的遗留系统,具体细节已遗忘。正文一直有个疑问,对于遗留系统,我们该如何TDD ?我个人比较认同TDD是一种设计方法,不能代替真正意义上的测试。是帮助我们设计自己代码的一种方法。...
487



被折叠的 条评论
为什么被折叠?



