想象一下,您正在实现包含各种新功能的用户故事,并增加了代码库的复杂性.现有代码已经很好地覆盖了,您刚刚决定了接口.您开始实施从测试开始的功能.
现在,根据需求,您拥有相当复杂的测试用例,但是当您能够提交SCM完全正常工作的代码并且许多测试失败时(实际应用),实现远未达到这一点.
假设在持续集成中,如果可能的话,所有构建都应该是绿色的,因此您不应该因为破坏构建而提交.但你也不应该"走向黑暗"并为自己保留这么多代码......
在这种情况下建议的程序是什么?
不要事先决定所有接口.在典型的TDD节奏中逐步发展:写一个测试; 让测试通过; 重构.这应该保持一切都很好,酒吧将始终是绿色的,你可以检查代码而不用担心你会打破构建.
它需要不同风格的编写代码,但你最终会习惯节奏.