| 关注 @alexbunardzic
加拿大不列颠哥伦比亚省温哥华市
Alex 自 1990 年以来一直从事软件开发。他目前的热情是如何将软性重新带回软件中。他坚信我们的行业已经达到了相当的成熟度，可以完全实现这一崇高目标（即将软性带回软件）。实现这一目标的绝妙方法之一是采用“快速失败”方法，即制定一个可衡量的目标/测试，然后迭代直到测试通过。 接下来，派出嗅探警察犬来检查货物（即使用变异测试），如果狗没有发现任何非法材料，则您的代码结构是最佳的。 这意味着它现在又变得柔软、易弯曲、柔韧。 这意味着您提高了业务运营的灵活性。
Alex 目前在 WorkSafeBC 担任顾问，该组织致力于以道德的方式对待安全的工作环境，以支持不列颠哥伦比亚省的雇员和雇主。 Alex 负责领导和确保组织层面的审慎软件工程实践。
要阅读更多 Alex 关于技术的文章，请访问他的博客：http://digitalexprt.com/blog.html
撰写的评论
好的，谢谢你提醒我。 我现在已将标题恢复到原始标题——“在测试驱动开发中，在编写代码之后编写单元测试被认为是有害的”
不，在 TDD 中，我们不依靠猜测。 我们遵循极限编程 (XP) 中实践的 3C 方法。
1. 卡片 (Card)
2. 对话 (Conversation)
3. 确认示例 (Confirmation examples)
它从业务制定一个假设开始。 例如，产品负责人想要发展他们的产品，他们集思广益并得出一个（或两个）假设。 然后，他们将该假设写在一张方便的卡片上。
然后，该卡片与团队共享，并引发进一步的对话。 你这句话是什么意思，你那句话是什么意思，你能否澄清这一部分，我可以建议这个想法吗，等等。在对话结束后，它应该产生一个或多个确认示例。 这些确认示例必须包含具体的值。
TDD 基于这些具体的值。 没有什么是留给猜测的。
如果企业/利益相关者无法提供具有具体值的确认示例，那么开始实施业务假设就没有意义了。 因为，如果你缺乏规范，你会实施什么？
仅仅交出一个愿望清单（类似于“我希望构建一个销量惊人并让我致富的产品！”）是行不通的。 在开始构建软件之前，必须提供更具体的细节和令人痛苦的细节。