unit-testing - 单元测试的目的 - 单元测试设计
我想知道应该为所有事情写单元测试吗？ 有一些类很难编写单元测试。 例如，我正在编写一些处理音频的程序。 从麦克风捕捉音频的类，以及为扬声器播放音频的类，如何为这些类编写单元测试？ 我不能得到这些类的输出和输入，所以几乎不可能测试它们？ 我能做的唯一的测试就是getter和setter，那些无聊的测试。 所以问题是，编写单元测试的指导是什么？ 而我应该如何处理这些难以测试的课程呢？
其他例子：如果你开发一个游戏引擎，你想测试你的阴影和其他功能，但你必须直观地确认它 - 这不是典型的UnitTest可以决定的。
你的情况：随着你的应用程序变得越来越复杂，点击你的用户界面来测试你的所有功能将会变得非常痛苦。
我将编写一个“交互式TestSuite”，其中显示了各种虚拟对话框（针对每个测试用例进行定制），仅显示您需要测试的功能。 关闭对话框后，系统会提示您是否预期该行为。 但我不确定是否有解决方案可以帮助这里。
我使用一个规则来决定是否开发单元测试：如果你的类（或任何单元）将被“释放”，那么你一定要考虑编写单元测试。
我的意思是：一旦你的代码将会处于一种你无法预测或控制事情如何与之交互的状态。 因此，通过API暴露的类或暴露给用户输入的类应该可以进行单元测试。
我个人认为，编写单元测试可能会浪费你的时间。 这真的是一个复杂的问题，你需要考虑：
- 这个班有多复杂？ 死简单的类可能不值得测试。
- 班级有多重要？ 运行在自动柜员机上的代码希望能通过单元测试。
- 你对班级的使用有多少控制？
然后总是：
- 项目截止日期是什么时候？
- 你有多少人力来创造测试？
- 你的要求是具体和详细的，还是班级还在不断变化？
至于困难的课程，也许读一下关于模糊测试 。
捕捉和重放音频的代码不能被单元测试（尽管你可以测试捕获方法在类未成功绑定到资源时调用时返回错误）。
但是，除非您只是将捕获的声音写入磁盘，否则调用捕获和播放类的代码当然可以。
两条建议：
- 不要测试编译器（比如getter和setter）
- 测试可能会中断的一切
简短的回答是，不，但是当你问：“IX应该做什么？
更长的答案是你至少应该考虑它，你在做什么。 你为什么不能把输入模拟成一个录音班？ 为什么不让类从麦克风旁路录音来加载文件中的音频，并将输出转到文件而不是扬声器。 测试可以将输出结果与已知的正确结果进行比较。
对于哲学方面更多的看到这一点 。
设计测试是一种获得的技能 - 越多，测试越好。 有些东西看起来很难测试，但如果你想了几分钟，你可以经常找到一种方法。
测试可能很麻烦 - 例如，一个Java程序可以启动一个解释器，甚至是一个像bash这样的shell，然后启动一系列的unix过滤器，希望能输出相同的二进制文件。 不要担心 - 测试代码的质量不必与成品中的代码一样高。
我测试大多数东西。
每当我写测试的时候，我也考虑将测试作为关于如何使用我的代码的文档或说明，供我和其他人在将来阅读。
虽然我不测试实现。 我希望能够改变实现而不改变我的测试。
我用TDD也许一年或两年，所以也许我会成熟和停止。 到目前为止，我还在学习，并认为我没有写足够的测试。
您可能想在我的博客中查看我的系列文章“测试不可能”，了解如何测试的一些想法。
在你的情况下，我建议遵循Steve Rowe的想法来写一个测试，设置扬声器和麦克风，并使用环回电缆来测试硬件设置代码，以及允许通过扬声器发射数据的API，麦克风。
这是一个单元测试，但不是自动化的。 将其移入独立的测试套件，该测试套件不会与其他自动测试一起运行。 如果要自动执行此操作，请使用正确的配置（加上回送电缆）安装第二台PC，然后远程运行测试。
之后，您确定硬件设置工作，您可以发送，您可以接收音频。 这使您可以独立于硬件测试数据处理类。 使用模型来模拟扬声器和麦克风。
