06 | 测试不好做,为什么会和设计有关系?
可测试性
- 深入了解
- 翻译
- 解释
- 总结
软件测试的困难与设计息息相关。大多数程序员在编写软件时往往忽视软件设计,导致代码难以测试。可测试性是软件对测试的支持程度,而不好测的代码往往意味着设计不佳。编写可测试的代码需要遵循软件设计原则,如SOLID原则,使代码符合单一职责原则、依赖倒置原则等,从而实现可组合的代码。避免使用static方法、全局状态和Singleton模式也是编写可测试代码的关键。此外,面对第三方代码集成时,隔离第三方代码和业务代码是关键,以确保第三方代码不成为测试的障碍。因此,软件测试的困难与设计息息相关,编写可测试的代码需要遵循软件设计原则,并且在集成第三方代码时需要进行有效的隔离。 在实际工作中,除了要编写业务代码,还会遇到第三方集成的情况。对于调用程序库的情况,可以定义接口,然后给出调用第三方程序库的实现,以此实现代码隔离。如果代码由框架调用,回调代码只做薄薄的一层,负责从框架代码转发到业务代码。提升软件的可测试性,关键是改善软件的设计,编写可测试的代码。编写可测试的代码是影响一个系统好不好测的重要因素,可测试性好的软件,各个模块都可以独立测试,而可测试性不好的软件,只能做整体的测试,其复杂度和过程中花费的时间都是不可同日而语的。
《程序员的测试课》,新⼈⾸单¥59
全部留言(18)
- 最新
- 精选
- byemoto对于不是以面向对象范式为核心的编程语言 (比如go), 需要做出一些针对性的调整吗? 在go语言中写出function主导的过程式代码还是比较普遍的.
作者回复: 单元测试的粒度一般都是一个函数。对于像 C 语言这种,要像做一个好的设计,需要付出一些更多的努力。 但如果你把 Go 归入到结构化编程,多半是低估了 Go 语言本身的能力,它只是表现面向对象的方式不同于常规的面向对象语言而已。
2021-08-184 - sylan215软件设计本身就是一个很重要的事情,但是大家都知道重要,落实的时候并不完全都按照设计原则来进行实现,加上所有项目都在赶工期,大家就真的完全关注实现了,先提测再说,成了首要目的。 这次通过老师说的可测试性要求,让软件设计的重要性再次提升,其实软件设计做好了,不仅仅有利于可测试,开发之间的 CR 也会进行的更顺畅(目前很多开发同学不愿意看别人代码,也和设计风格千变万化有关,喔,对了,其实大部分都没有设计)。 目前我们准备试推行技术评审,会考虑把可测试性要求也加到技术评审的环节,多谢老师提醒。
作者回复: 做得好的都很简单,做不好的,千奇百怪。
2021-08-184 - إ并向你招手إ祥子目前团队在使用sonar 作为代码质量的管理工具,其中有一条规则,没有属性依赖的方法应该是static 方法,但这种static方法实际上并没有为测试增加障碍,反而是更容易写测试的,不需要任何外部依赖,也不用做测试准备,连实例化都不用,直接调用对输入输出进行检查即可
作者回复: 这种情况和我说的属于基础库是类似的,大部分人其实是很少有机会写这样的代码,这也是我建议从整体上规避写static的原因。
2021-08-174 - lanlyhs赞,老师为单元测试的痛点指出了明路。 我们的系统现在全是 static 方法.... 只能在外围做一些接口测试 ,非常痛苦。
作者回复: 听上去就很痛苦
2021-08-164 - Geek_3b1096目前代码库很多Singleton getInstance()
作者回复: 难以测试,需要改。
2021-08-302 - Geek_452877我还是比较赞同“测试不好写(或难以)写,是设计不好导致的”,测试要好写,函数的耦合性就要低,函数的功能就必须单一。但一个现实的问题是:总有人(模块)要去负责组合这些功能,例如我用静态方法给外部模块提供一个较友好的接口。这不是很好么? 例如,外部不操心整个过程,只关心最后的结果!比如一个makcall 的静态函数
作者回复: 能用静态方法的,不能用普通方法吗?为啥一定要执着于静态方法呢
2021-10-061 - 飞翔老师 工具类 是不是应该用static?
作者回复: 理论上是可以的,但真正值得写成工具类的并不多
2022-10-24归属地:陕西 - aoe又学到了:用中间层隔离实现细节!老师的中间层用的非常6啊2021-11-094
- Luke我是做测试的,以前看书籍的时候,多次接触到可测试性的概念;总是不能理解,原来软件的可测试性是落实在软件设计和具体的编码实践上的。2021-09-141
- 利刃方开老师好,这句话“如果我们的代码由框架调用,那么回调代码只做薄薄的一层,负责从框架代码转发到业务代码”,有什么学习资源推荐下么?不是太理解如何去这么做2023-05-25归属地:安徽1