×

Loading...

@Vancouver

Topic

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越早发现并修复，成本越低。 -tracyd(等待明天); 2021-2-21 {40} (#13533461@0) +1
          if one
          else two
          if three
          else four
          • 问题是这些逻辑你联合测试也得做，联合测试不用做的，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)

More Topics

  • The two assumptions we need about the cost function
  • 很佩服能够静得下心做学问的人。ZT: 图灵奖揭晓！史上首位数学和计算机最高奖“双料王”出现了
  • 谁来计算一下，$500块钱能买多少度电，让一辆大约2000磅的车跑多少公里？网友跑了2.5万公里，另外$500的汽油呢？
  • 这次日食效果太差了，
  • What are Dendrites?
    • 枫下论坛主坛 /  工作学习 /  学科技术