我想知道我应该为所有东西编写单元测试.有些类很难编写单元测试.例如,我正在编写一些处理音频的程序.用于从麦克风捕获音频的类,以及用于播放音频到扬声器的类,如何为这些类编写单元测试？我无法获得这些类的输出和输入,因此几乎不可能测试它们？我唯一能做的测试就是吸气器和定位器,那些无聊的测试.所以问题是,编写单元测试的指导原则是什么？我应该如何处理这些类很难测试？
在有意义的地方使用单元测试 - 不要以100%的覆盖率为目标.主要准则是思考而不是应用教条或懒惰.
话虽如此:如果你有自然难以测试的课程,试着减少他们必须做的事情.隔离不可测试的代码并将其API分离到一个接口中.然后测试对模拟或存根使用该API 的逻辑.
我只写单元测试,我知道它可以节省我的时间.当我开始进行单元测试时,这只是一小部分类(那些可怕的ejb !!).今天我几乎测试了所有东西,我节省了每一件事的总开发时间.如果有一种通过麦克风测试用户输入的有效方法,我也会这样做.但据我所知,以某种方式节省时间是不可能的.
所以我认为你应该对当前"测试能力"中的所有内容进行单元测试.你应该尝试扩展这种能力,但过度扩展确实会发出错误优先级的信号; 很有可能还有其他一些值得你注意的测试.(从技术上讲,我是测试感染但未感染TDD)
收益递减法则适用于单位测试,与任何其他测试一样多; 您在最后5%的回报率非常低且成本很高.
京公网安备 11010802040832号 | 京ICP备19059560号-6 