Answers:
红色是答案。红色是您无法从TDD的红色-绿色重构周期中获得的，最后一次测试。首先，编写一个失败的测试。观看失败。那是你的红色，这很重要。它说：我有这个要求，我知道我的代码不能满足要求。因此，当您转到第2步（绿色）时，就可以肯定地知道您的代码现在已满足该要求。您知道您已经按照满足要求的方式更改了代码库。
在基于代码的代码之后开发的需求（测试）剥夺了您这种确定性和信心。
如果先编写代码，然后编写测试，那么很容易陷入编写测试的陷阱，以使代码通过，而不是编写测试以确保代码符合规范。
也就是说，这绝对不是唯一的处理方法，也没有“最佳”的软件开发方法。如果您将大量的前期工作投入到开发测试用例中，那么直到很久以后您才知道所提议的体系结构是否存在缺陷-而如果您首先开发了代码，则可以更快地将其投入使用，并且可以减少沉没的情况下进行重新设计。努力。
实际上，人们对TDD感兴趣的是测试，尽管他们忘记了首字母缩写词中的其他两个字母。可以在这里阅读的内容：没有T或TDD的TDD与Testing无关。
事情是，我学到了很多其他与TDD紧密相关的东西。不需要先进行测试就没关系：重要的是考虑软件设计。
为了甚至能够以“正确的方式” 编写单元测试，即使它们独立，快速且自动化，您希望会注意到，它需要重新思考如何以简化代码的方式安排代码去测试。
我个人不了解SOLID原理，而是学会了SOLID原理。这是因为编写单元测试迫使我重写类，这样它们就不会变得过于复杂而难以测试。它导致类似：
即使我不是一直都在进行测试，但我确实遵循了您开始遵循的良好的面向对象原则和实践，只是使测试变得更加容易。现在我不是为了自己而编写代码。我编写了代码，因此可以轻松对其进行测试或更重要的是，易于维护。
如果您首先编写测试，那么它会给您另一个机会来思考您的设计，然后再将其“付诸实践”。
例如，您可能认为您需要一种采用一组特定参数的方法。而且，如果您首先编写了代码，则将以这种方式编写，并使测试适合指定的参数。但是，如果您首先编写测试，您可能会想“等一下，我不想在主线代码中使用此参数，所以也许我应该更改API。”
我看到很多建议，开始编写测试，然后再进行编码，
这确实有充分的理由。
如果您说“做正确的事”，人们就会做最愚蠢，最疯狂的事情。
如果您说“首先编写测试”，那么人们至少可以尝试做正确的事情。
如果我用另一种方法做的话有什么缺点-编写代码然后进行单元测试？
通常，糟糕的测试和必须重新设计才能测试的设计。
但是，这只是“通常”。有人并行开发设计和测试。有些人将可测试的代码放在适当的位置，编写测试而无需返工。
“测试优先”规则专门用于教导和指导完全不了解的人。
以类似的方式，总是告诉我们过马路之前要“双向看”。但是，实际上我们没有。没关系。我住在右驾国家，开始穿越时只需要向左看。
当我访问左驾国家时，向左看只会使我丧命。
出于某些原因，对规则的说明非常严格。
您要做的是您自己的问题。
首先，如果您不首先编写测试，那么您就没有进行测试驱动开发（TDD）。好处是很多的，通常很难相信，除非您多次练习。与传统开发相比，以下是我在使用TDD时获得的好处：
书籍：Beck，K.通过示例进行测试驱动的开发
很好的例子：http : //jamesshore.com/Blog/Lets-Play/