This topic has been archived. It cannot be replied.
-
工作学习 / 学科技术 / 你们觉得Unit Test有用吗？我对它们一点信任感都没有，顶多只能避免一点低级错误，完全不值得费那力气去写。只有做完Integration test后心里才踏实点。
-hiker2(过客);
2021-2-21
(#13533426@0)
+2
-
Unit test属于开发，码工自己做的，确实应该只能纠正低级的程序错误。理念是好的，做起来有点麻烦，除非部门有强制要求，否则真没见过有人主动去做。
-youbet(🍑);
2021-2-21
(#13533434@0)
-
有用。把unit里所有该走的逻辑和路径都走一遍。可以提高很多效率，少很多bug。
-tracyd(等待明天);
2021-2-21
(#13533443@0)
+3
-
你们要求覆盖率100%？这是多大的浪费啊。
-hiker2(过客);
2021-2-21
(#13533450@0)
-
这2个if else难道不用去都走至少一次，就扔给QA做黑盒?QA的劳动力成本自然得大幅提高。另外，bug越早发现并修复，成本越低。if one
else two
if three
else four
-tracyd(等待明天);
2021-2-21
{40}
(#13533461@0)
+1
-
问题是这些逻辑你联合测试也得做，联合测试不用做的，UT也一般犯不着做。
-hiker2(过客);
2021-2-21
(#13533505@0)
-
SIT测试的时候，基本上都是黑盒，里面的code是看不到的。根本不知道你有几个if then。否则就不叫黑盒了，叫白盒。
-tracyd(等待明天);
2021-2-21
(#13533668@0)
-
赞， Unit Test是必须的，否则做Integrated Test会很费时费力，这个顺序必须走，以提高效率
-111111(快乐老家);
2021-2-21
(#13533494@0)
-
Unit test不是自动生成的吗
-mapleforum(maple_wizard);
2021-2-24
(#13538728@0)
-
+1
-geekcode(文心雕码);
2021-2-21
(#13533889@0)
-
DCUT的每一步都是软件开发必须，没有UNIT test，后面的integration test 就会变得毫无意义
-keysi(K.S);
2021-2-21
(#13533444@0)
+1
-
Unit test不过是软件开发里比较新近的事物，以前的开发测试都无意义？
-hiker2(过客);
2021-2-21
(#13533454@0)
-
旧东西了，junit,nunit都至少有二十年历史了。到现在也没有太火，正说明了它的问题。很多IDE会自动生成一个test project, 有些指南上教人首先要删除它，免得老报错😂
-youbet(🍑);
2021-2-21
(#13533463@0)
-
软件的历史要长得多
-hiker2(过客);
2021-2-21
(#13533487@0)
-
我说的可是java/.net里面的工具包啊，而且俺说的是至少啊，懒得去考古而已。再远了企业还不太用软件呢。
-youbet(🍑);
2021-2-21
(#13533538@0)
-
曼哈顿工程了解一下
-hiker2(过客);
2021-2-21
(#13533585@0)
-
对于软件开发来说，java/.net还不算新东西？
-guestagain(guest again);
2021-2-21
(#13533592@0)
-
自打有代码开发起，就有unit test.
-tracyd(等待明天);
2021-2-21
(#13533466@0)
-
不是现在意义上的unit test
-hiker2(过客);
2021-2-21
(#13533483@0)
-
DCUT的每一步都需要有质量管理，design需要architect review，coding需要peer review, unit testing是保证你每个module、method都能正常工作，在这个前提下integration testing才有意义，integration testing是不可能测到method level的所有细节的
-keysi(K.S);
2021-2-21
(#13533471@0)
-
UT不能保证module/method都能正常工作。它有点像逻辑学里的形式逻辑，只能保证形式正确，不能保证现实逻辑正确。
-hiker2(过客);
2021-2-21
(#13533496@0)
-
UT应该做到module level单独都能正常工作，不管任何input, output都应该是期望值
-keysi(K.S);
2021-2-21
(#13533500@0)
-
您是明白人，赞👍
-111111(快乐老家);
2021-2-21
(#13533497@0)
-
很多公司对unit test的理解是错的。Test应该从验收标准开始写，而不是从class上写，很多公司从class上写，结果class一变，test又要重写，这是不对的
-gta_palace(呄 - 每天乃古);
2021-2-21
(#13533456@0)
+1
-
unit test 的精髓是保证 code 是 unit testable （testable， testable, 重要的事情说三遍） -- 一段 code 如果 testable 一般不会坏到哪里去，需求变了也容易重构。
-xmlhttprequest(build5381);
2021-2-21
(#13533509@0)
-
可testable和usable是两个概念，你的目标是usable而不是testable，凭空增加一个要求，你以为不需要成本？
-hiker2(过客);
2021-2-21
(#13533517@0)
-
这个“凭空增加的要求” 是 --- 软件的质量保证。你要是说我们不需要，那咱就不用写。好比老板问“我只要成品软件，你们干嘛要买电脑，你以为不需要成本？”
-xmlhttprequest(build5381);
2021-2-21
(#13533529@0)
-
没有电脑你写不了程序，没有UT也可以写正确的程序，区别于此。
-hiker2(过客);
2021-2-21
(#13533580@0)
-
不写 UT, 好的 dev 也能写出不但正确，而且解耦的程序；但很多 dev 会写出现在能 work 但非常耦合，非常 spaghetti，非常难以重构的 code，所以业界提倡 unit testable。
-xmlhttprequest(build5381);
2021-2-21
(#13533598@0)
-
况且现实中有多少是在老代码上重构？还不多是弃了重写？
-hiker2(过客);
2021-2-21
(#13533519@0)
-
大部分产品发布后都要增加，合并一些 features，肯定会有些重构 --- 这也全都弃了重写？这会儿又不考虑“成本”了？
-xmlhttprequest(build5381);
2021-2-21
(#13533579@0)
-
“一段 code 如果 testable 一般不会坏到哪里去”…… 你认真的？
-guestagain(guest again);
2021-2-21
(#13533528@0)
-
是的，我认真的 --- 如果 testable，那就很容易用 unit test 来证明它 work 或不 work，就算没有 unit tests，也容易review code看出问题 --- 相比起公司祖传千年 spaghetti 好太多。
-xmlhttprequest(build5381);
2021-2-21
(#13533541@0)
-
testable但是永远不work的code，嘿嘿……
-guestagain(guest again);
2021-2-21
(#13533545@0)
-
你要是觉得很好笑，想想以下两个场景：1. “我们发现这段 code 虽然有 unit test，但不 work，可能缺了一个 test case，你来看看？” 2. "这段公司祖传千年 spaghetti 一个 method 有 2 万行 code，但 work 得很好，这周我们要加个 feature，你来做。"
-xmlhttprequest(build5381);
2021-2-21
(#13533569@0)
-
我只是针对“一段 code 如果 testable 一般不会坏到哪里去”而言，你愿意扩展到哪里是你的事。
-guestagain(guest again);
2021-2-21
(#13533576@0)
-
Testable的设计本身有时会改进软件质量，有时不会，所以我做这个的时候会根据是否改善软件质量来决定是否加testable设计
-wuyg719(平平);
2021-2-21
(#13533623@0)
-
有一种职位叫software development in Test。SDET就是专门做这种测试的。
-tracyd(等待明天);
2021-2-21
(#13533675@0)
-
ZT: The benefits of unit testing are: Decouples your code / Write more modular classes / Functions are smaller and more focused / Your functions are more defensive / Quality of code becomes higher / You will find it easier to reuse code.
-xmlhttprequest(build5381);
2021-2-21
(#13534251@0)
-
哈，抬杠一下，也容易迷失在unit的海洋中……
-guestagain(guest again);
2021-2-21
(#13534254@0)
-
哈哈，现在都是只讲好处不提坏处的
-hiker2(过客);
2021-2-21
(#13534307@0)
-
另外一点：其实，有时候 UT 是保护 dev 的 -- 很多 dev 说，需求稍稍一变，30% 的 unit tests 就废了 -- 但这其实正是 point：在 TDD 里，unit tests 通常反映 business rules，要是 30% 的 tests 废了，PO/PM 需要了解 -- 这不是他们以为的“小变更”。
-xmlhttprequest(build5381);
2021-2-21
(#13533618@0)
+1
-
尽量externalize business rule，让业务部门自己负责。他们要改business rule，就让他们自己去测。
-iamflying(叶和花);
2021-2-21
(#13533843@0)
-
这个主意本身很好，不过有时候 metadata driven rule engine 很不容易设计 --- 取决于行业。
-xmlhttprequest(build5381);
2021-2-21
(#13533910@0)
-
设计这种系统需要经验的积累，能够预测可能出现的需求。
-iamflying(叶和花);
2021-2-21
(#13533939@0)
-
以前碰到过这样的需求，当时还没有现成的商用 rule engine --- 最后发现不是很值当。
-xmlhttprequest(build5381);
2021-2-21
(#13534117@0)
-
传统上unit test是开发做，integration test是测试做，但是效果就见仁见智了。随着devop/自动化的发展，现在integration test逐渐也进入开发流程里，这种效率和实用性都更强了。
-negation(否定之否定);
2021-2-21
(#13533868@0)
-
code 和 unit test 往往都是一个人写的，两部分的水平也一样。业务逻辑搞错了，测试逻辑也会跟着错，这个在 unit test 里面很常见。
-negation(否定之否定);
2021-2-21
(#13533877@0)
-
Unit test是为了避免改代码以后break现有的逻辑。要验证逻辑，还需要第二人(QA)
-iamflying(叶和花);
2021-2-21
(#13533887@0)
-
这个 integration test 一样可以做到的，而且做的更好。
-negation(否定之否定);
2021-2-21
(#13533891@0)
-
两个不同的level。Unit test更快，每次local build都跑一遍。integration的频率低，但覆盖面广。
-iamflying(叶和花);
2021-2-21
(#13533893@0)
-
local build 跑integration test 现在很常见了吧。docker 威武。
-negation(否定之否定);
2021-2-21
(#13533912@0)
-
可以跑Integration test，但花费时间要长一些。当然，也因为如此，开发人员不必太过纠缠于unit test coverage
-iamflying(叶和花);
2021-2-21
(#13533936@0)
-
到了intergration再测就有点晚了，扔到QA去测，成本也增大，有一些细节还不一定能测得到，除非用白盒测试，或者QA去读你的code。那工资也得涨上去，和你一样高，甚至比你高才行。
-tracyd(等待明天);
2021-2-21
(#13534099@0)
-
很多书籍的例子是一边写class一边写unit test，那些例子简单的可笑，比如什么getXXX然后setXXX。设计一改，test就没用了。unit test实际上强化了现有code的钢度。
-gta_palace(呄 - 每天乃古);
2021-2-21
(#13533941@0)
-
这种问题还有人问，真是太惊奇了。工人上岗要不要戴安全帽？医生做手术要不要戴手套？早就是行业标准了
-geekcode(文心雕码);
2021-2-21
(#13533903@0)
+1
-
这还真没有什么行业标准。现在公开的Test标准是IEEE的，没有提到Unit Test. 实践中各种理解都有。
-gta_palace(呄 - 每天乃古);
2021-2-21
(#13533920@0)
+1
-
晕倒，ISO/IEC/IEEE12207是干啥的啊
-keysi(K.S);
2021-2-21
(#13534132@0)
-
你读过嘛，我可是20年前就读过。这个东西一直是IEEE的，2017成为ISO，文本没改
-gta_palace(呄 - 每天乃古);
2021-2-21
(#13534147@0)
-
是没怎么改，后面的methodology和framework都是根据这个出来的，DCUT中的unit testing一直就有啊
-keysi(K.S);
2021-2-21
(#13534175@0)
-
还是有用的只是效率没那么高。第一，保证各模块不出很stupid的错误，第二，unit testing过程中积累了测试用例，集成测试时可以参考，以免最后漏掉了什么。
-laohu667(老虎 667);
2021-2-21
(#13533904@0)
-
一个模块要处理的scenario如果很多，是需要写unit test的。三言二语讲得清楚的，当然可以不用写。
-retirecat(☁️);
2021-2-21
(#13533943@0)
-
可以Unit Test，至少代码比较干净，否则你都不知道该怎么测。
-cricketkiller(白牙青);
2021-2-21
(#13534326@0)
-
这个东西跟政治比较像：不能极左，也不能极右，不能没有unit test，也不能有太多的unit test
-wuyg719(平平);
2021-2-21
(#13534344@0)
+1
-
unit test=参选人自己搞的民调； integration test=三方民调
-negation(否定之否定);
2021-2-22
(#13535119@0)
-
没啥用，机器不会写代码，测试也要人写，真正的漏洞一般是用户发现的，
-googlebot(bot);
2021-2-22
(#13536007@0)
+2
-
UTest的真正用途是程序员用来对BA，PM甩锅用的。。。。。
-zhengy4(_);
2021-3-11
(#13567090@0)