我可以看到用于为某些代码构建自动化测试的用途：具有更多小功能的库，具有大量引用的核心功能等。基本上，随着一段代码的价值通过大量使用，我可以看到它会对自动测试代码越来越有价值，所以我知道我不打破它。
然而，在我的情况下，我觉得很难合理化任何东西。我会采用的东西，因为它们证明有用，但我不会盲目跟随任何东西。
我发现我在“维护”中做的很多事情实际上是小的设计更改。在这种情况下，测试不会救了我什么，现在他们也必须改变。一个高度迭代，stub-first设计方法对我来说非常好。我不能看到实际上保存自己这么多时间与更广泛的测试。
爱好项目甚至更难以证明…他们通常是从周末到长达一个月的任何东西。边缘错误很少重要，它是所有关于玩的东西。
阅读问题，如this one，最投票反应似乎说，在海报的经验/意见TDD实际上浪费时间，如果你有不到5人(即使假设一定水平的能力/ TDD经验)。然而，这似乎涵盖了初始开发时间，而不是维护。目前还不清楚TDD如何在项目的整个生命周期中累积起来。
我认为TDD可能是提高整个行业产品质量的有价值的目标的一个很好的一步。理想主义在它自己的不再是有效的激励我，虽然。
我认为TDD将是一个很好的方法，在大型团队，或任何规模的团队包含至少一个不可靠的程序员。这不是我的问题。
为什么一个拥有良好记录的独立开发者采用TDD？
我很愿意听到任何种类的指标(正式或不是)在TDD …专注于独立开发人员或非常小的团队。
没有，你的个人经验的轶事也会很好。
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。