在底层组件上进行TDD是个好主意吗？

我正在考虑编写低级驱动程序或OS组件/内核。

该osdev.org人们似乎认为重要的位没有有意义的可测试这种方式，但我看过一些讨论，有人认为是不同的。我环顾四周，但未能在低级组件上找到任何TDD的实际示例。

这是人们实际上在做的事情，还是人们在理论上谈论的事情，因为在实践中没有好的方法？

如果您正在与硬件交互或控制硬件，那么没有它很难进行测试。您可以尝试仿真硬件，但这通常比首先编写驱动程序难，因此您最终不知道该错误是在驱动程序中还是在仿真器中。

我个人倾向于相信，可以通过以下方式获得TDD的许多好处（实际上并没有遵循TDD）：

• 大约同时（绝对不超过24小时）同时编写呼叫者和被呼叫者代码。
  • 并以此来影响接口的设计（对象，方法调用和参数）。
• 对于需要复杂算法/代码的组件，强烈考虑首先使用更简单但正确的算法来实现，即使效率较低（或愚蠢，或仅在较窄的情况下有效）。
  • 一种非常简单的测试方法是同时运行这两种算法并比较其结果。
• 一旦（无论如何）在代码的一部分中发现了错误，就应该更积极地测试那部分代码。这意味着进行比TDD要求的更为复杂的测试。（基于在群集中出现错误的原因）

TDD似乎要求您对计划实现的功能或计划通过实现代码满足的要求有清楚的了解。在某些情况下，对问题的了解太少了。这本来需要Spike解决方案。在此Spike解决方案的范围内，可以应用TDD，因为该问题已缩小到可管理的水平。一旦完成了几次Spikes，每个Spikes都涵盖了原始问题的某些方面，就可以开始研究完整的解决方案，并且由于理解的提高，此时应用TDD可能是可行的。

编辑：

仔细阅读页面后，

虽然应该可以在“测试床”测试驱动程序中测试大多数内核功能，但真正“多汁”的东西（例如中断处理，进程分派或内存管理）可能无法进行单元测试。---来自http://wiki.osdev.org/Unit_Testing

他们明确地说，大多数零件都是可测试的，并且某些零件需要另一种测试：压力测试。

我不。在我的主人的嵌入式代码中，我只是编写代码，并花时间思考它做什么（和不做什么）。我不确定无论如何我都可以做到这一点，在不注入测试代码的情况下，我越来越接近内存的物理极限。

我认为对于足够大的系统（即具有MB的内存而不是KB的内存），如果有足够的时间和精力，可以对某些组件完成此操作。通过模拟引脚来测试引脚读取代码是……不是很有意义。如果您已将逻辑分离出来，则可以在其他地方测试逻辑。

FWIW，在一般情况下，我不购买TDD-它对于足够大且具有足够确定性行为的足够资源的系统堆栈工作正常，除此之外，这似乎不是合理的做法。