我学到的是在生产环境和/或紧急时间内，没有实验性代码。通常会进行实验直到某个点“可行”，这时它就成为了生产代码。
另一方面，从一开始就采用TDD会导致你的代码设计更好。你会更多地思考、重构和频繁地改进代码，而不是事后再编写测试。
我事后编写了测试。迟到总比不到好。它们总是值得拥有的。
然而，我必须说，第一次在编写被测试代码之前编写测试，感觉非常令人满意。不再需要手动测试。我很惊讶它的效果如此之好。
此外，我倾向于在重构遗留代码之前编写单元测试 - 这几乎意味着我正在编写测试来测试已经编写的代码。提供了一个安全保障，使我更舒适地进入由他人编写的大块代码。
“我不确定这是否是一个好的方法（绝对不是最好的）。”
不好吗？为什么？
你是在设计可测试性吗？在这种情况下，你的设计是测试驱动的。还有什么更多的要求呢？
无论测试是先进行、中间进行还是最后进行，都没有设计可测试性重要。最终，对设计的更改会使测试失败，然后你可以修复问题。对于预测设计更改而进行的测试更改也会使测试失败。这两种方法都可以。
如果你完成了设计工作，但在中途遇到了难以测试的部分，那么你就没有做好TDD。你需要重构你的设计，使其可测试。
我经常采用你所说的方法。看起来有效的方法是将实验代码视为实验代码，然后根据你所学到的知识开始进行适当的设计。从这里开始，你可以先编写测试。否则，你就会留下许多被编写为临时或实验性代码的代码，并且可能无法为其中所有代码编写测试。
我通常先写测试，但有时在尝试时会先写代码。一旦我明确了我的代码应该做什么，我就停止编写代码并开始测试。
VS 2008有一个很好的功能，可以为对象生成测试类，测试需要进行微调，但它可以为您完成大部分繁重的工作。这对于为您不太勤奋的同事创建测试非常有用。
另一个好处是它有助于防止您错过某些东西，特别是当您在处理不属于自己的代码时。
如果您使用的是不同的测试框架而不是MSUnitTest，则将测试从MSUnit转换为Nunit等相对简单，只需进行一些复制和粘贴即可。
当你试图弄清楚代码如何工作时，先编写代码是很自然的。但是，先编写测试可以帮助你确定代码应该做什么（而不是如何做）。如果你先编写代码，那么你正在尝试在完全定义问题之前解决问题。这并不一定是“坏事”，但你正在将单元测试用作回归工具而不是开发工具（再次强调，这并不是“坏事”，只是不符合TDD的原则）。
我想说，我总是先写单元测试，但当然我并不总是这样做（对于任何真正的程序员来说，这是众所周知的原因 :-)). 我（好吧，也不总是总是...）做的是将每个花费我超过五分钟时间才能找到的错误转换成一个单元测试。甚至在我修复它之前。这有以下优点：
