我是一个有很多经验的合同程序员。我习惯于被一个客户聘请进去，做一个或另一个我自己的软件项目，通常从没有。这意味着一个干净的板岩，几乎每一次。我可以引入我开发的库以快速启动，但它们总是可选的。 (并且取决于在合同中获得正确的IP子句)很多时候，我可以指定或甚至设计硬件平台…所以我们在这里谈论严重的自由。
我可以看到用于为某些代码构建自动化测试的用途：具有更多小功能的库，具有大量引用的核心功能等。基本上，随着一段代码的价值通过大量使用，我可以看到它会对自动测试代码越来越有价值，所以我知道我不打破它。
然而，在我的情况下，我觉得很难合理化任何东西。我会采用的东西，因为它们证明有用，但我不会盲目跟随任何东西。
我发现我在“维护”中做的很多事情实际上是小的设计更改。在这种情况下，测试不会救了我什么，现在他们也必须改变。一个高度迭代，stub-first设计方法对我来说非常好。我不能看到实际上保存自己这么多时间与更广泛的测试。
爱好项目甚至更难以证明…他们通常是从周末到长达一个月的任何东西。边缘错误很少重要，它是所有关于玩的东西。
阅读问题，如this one，最投票反应似乎说，在海报的经验/意见TDD实际上浪费时间，如果你有不到5人(即使假设一定水平的能力/ TDD经验)。然而，这似乎涵盖了初始开发时间，而不是维护。目前还不清楚TDD如何在项目的整个生命周期中累积起来。
我认为TDD可能是提高整个行业产品质量的有价值的目标的一个很好的一步。理想主义在它自己的不再是有效的激励我，虽然。
我认为TDD将是一个很好的方法，在大型团队，或任何规模的团队包含至少一个不可靠的程序员。这不是我的问题。
为什么一个拥有良好记录的独立开发者采用TDD？
我很愿意听到任何种类的指标(正式或不是)在TDD …专注于独立开发人员或非常小的团队。
没有，你的个人经验的轶事也会很好。 原文链接：https://www.f2er.com/javaschema/282535.html
