我一直在研究测试驱动开发的学科，对我来说，它在实现算法和输入输出系统方面效果很好。
据我所知，TDD的“本质”是针对应用程序的每个需求实际编写测试。通常，此要求定义了具有输入和输出的行为。
所以，现在。进入实时应用程序。假设您的应用程序运行无限循环。一个常见的示例是图形应用程序或音频应用程序，其中循环的每次迭代都意味着将输出输出到屏幕/扬声器。
具有这样的系统，要求是这样的：“按Enter键时，屏幕上应显示一个圆圈，圆圈内有文字Hello World”
所以您将如何测试满足这种要求。
另一个例子，只是为了更好地说明我的问题。假设我在仿真CPU。在每次迭代中，我都从文件中获取操作码，将其翻译并执行。基本上没有实际输出。发生的事情是输入改变了一些与CPU仿真有关的状态。因此，没有用于CPU内部的公共接口。
我的要求是说“在cpu模拟器上执行mov操作”这可能是“实现操作码仿真”这一更大要求的一部分]
所以使用TDD解决这种行为/要求的好方法是什么？
使用TDD解决这种行为/要求的好方法是什么？
我通常看到的情况是设计被分成两部分
基本上，您正在安排“风险”主要位于易于测试的代码中。
真正简单的代码属性之一：它也往往非常稳定。低风险，稳定和难以测试的结合意味着在这里投资测试自动化的吸引力降低。
基本上没有实际输出。
写无操作；做任何没有明显副作用的工作都是没有好处的。
这是常见的模式，我们关注输出的中间阶段。例如，如果我们要从扬声器产生声音，那么我们在代码中可能要做的就是在选择声音的工作与将声音表示传递给扬声器的实际机制之间建立一个接缝。在此接缝处，我们还捕获了信息，以便我们可以对其进行检查。
因此，没有用于CPU内部的公共接口。
具有测试界面通常是令人满意的结果。通常，您会发现您想发布测试界面，以用于满足监视或可观察性要求。
公共接口太宽泛，无法测试单个行为。
是的，这很常见。通常的反应是将您的广泛的可测试模块重构为几个，甚至很多狭窄的可测试模块。复习Parnas 1971。
考虑公共方法（可在模块外部访问）和published methods（可通过you
无法控制的代码访问）之间的区别也可能会有所帮助。