为有很多全局量的代码增加测试是很有挑战的，一个测试可能会因为另一个测试留在全局量里的状态信息而遭到破坏，另一件同样的坏事是其他测试开始依赖于这种状态。测试是代码职责的文档,并确保任何将来Time函数的错误都能直接被它自己的测试所捕获，而不是其他测试的副产品。一旦感知到了代码中的不对的地方，接下来就要利用我们对代码和设计的知识来预想到一个更好的解决方案。从Lightscheduler的角度来看，Ti

测试驱动开发(TDD)是一种增量式软件开发技术。简单地说，就是在没有失败的单元测试的前提下不可以写产品代码。这些测试要很小,而且要自动化。用测试来驱动其实很合理。相对于直接写产品代码，TDD的实践者们会先用测试来表达他们希望产品代码会有什么样的行为。然后这个测试显然会失败。只有在这时，他们才开始写产品代码;以便让测试通过。在测试驱动开发LightScheduler时，测试夹具通过截获对TimeSe

最近修复的一个bug让我对AI在软件质量测试及BUG修复上的应用有了新的期待。