我应该为所有东西编写单元测试吗？

Question

我想知道我应该为所有东西编写单元测试.有些类很难编写单元测试.例如,我正在编写一些处理音频的程序.用于从麦克风捕获音频的类,以及用于播放音频到扬声器的类,如何为这些类编写单元测试？我无法获得这些类的输出和输入,因此几乎不可能测试它们？我唯一能做的测试就是吸气器和定位器,那些无聊的测试.所以问题是,编写单元测试的指导原则是什么？我应该如何处理这些类很难测试？

Answer 1

在有意义的地方使用单元测试 - 不要以100%的覆盖率为目标.主要准则是思考而不是应用教条或懒惰.

话虽如此:如果你有自然难以测试的课程,试着减少他们必须做的事情.隔离不可测试的代码并将其API分离到一个接口中.然后测试对模拟或存根使用该API 的逻辑.

Answer 2

我只写单元测试,我知道它可以节省我的时间.当我开始进行单元测试时,这只是一小部分类(那些可怕的ejb !!).今天我几乎测试了所有东西,我节省了每一件事的总开发时间.如果有一种通过麦克风测试用户输入的有效方法,我也会这样做.但据我所知,以某种方式节省时间是不可能的.

所以我认为你应该对当前"测试能力"中的所有内容进行单元测试.你应该尝试扩展这种能力,但过度扩展确实会发出错误优先级的信号; 很有可能还有其他一些值得你注意的测试.(从技术上讲,我是测试感染但未感染TDD)

收益递减法则适用于单位测试,与任何其他测试一样多; 您在最后5%的回报率非常低且成本很高.

Answer 3

我用来决定是否开发单元测试的一条规则：如果您的类（或任何单元）将被“公开”发布，那么您绝对应该考虑编写单元测试。

“在野外”，我的意思是：一旦您的代码将处于您无法预测或控制事物将如何与其交互的情况下。因此，通过 API 公开的类或向用户输入公开的类可能应该进行单元测试。

就个人而言，我认为为所有内容编写单元测试可能是在浪费您的时间。这确实是一个复杂的问题，您需要考虑：

• 班级有多复杂？死简单的类可能不值得测试。
• 这门课有多重要？希望在 ATM 上运行的代码进行单元测试。
• 您对类的使用方式有多少控制权？

然后总是：

• 项目截止日期是什么时候？
• 您投入了多少人力来创建测试？
• 您的要求是否具体和详细，或者课程是否仍然经常变化？

至于难点的课，不妨多读读fuzz testing。