Tracer Bullet 开发 [关闭]

Question

我正在使用The Pragmatic Programmer 中提倡的 Tracer Bullet 方法开发客户端服务器应用程序，并希望得到一些建议。我正在处理从客户端启动到服务器并再次返回客户端以显示结果的每个用例。

我可以看到两种方法：

1. 涵盖基本用例，仅 编写足够的代码来满足 我正在处理的用例，然后返回 并充实所有的错误处理 稍后。
2. 充实每个用例 可能，捕获所有异常并完善界面，然后再继续 下一个用例。

我倾向于第一个选项，但我害怕忘记处理一些异常并在应用程序投入生产时让它咬我。或者留下不清楚的“存根”错误消息。但是，如果我采取第二种选择，那么我想我以后会做出更多的改变。

问题：
在使用示踪子弹开发时，您采用这两种方法中的哪一种？为什么？
或者，我还缺少另一种方法吗？

Answer 1

据我了解，Tracer Bullet 方法有两个主要目标

1. 尽快解决根本问题
2. 尽快给客户一个有用的结果

您不“打磨”每个用例的动机可能是为了进一步加快 2.问题是这样做是否会危害 1. 以及客户是否真的对“未完善”的结果感兴趣。即使没有，beng 能够快速获得客户的反馈肯定是有优势的。

我会说你的想法是可以的，只要

• 确保“未抛光”部分中没有隐藏任何基本问题 - 错误处理肯定会发生这种情况
• 您可以稍后在问题跟踪器中或通过将 TODO 留在源代码中来跟踪您必须“完善”的任何内容 - 并在用例正常工作后仔细检查这些内容
• 用例并非如此“粗糙”，以至于客户无法/不会给您提供有用的反馈

Answer 2

如果您采用方法 1，您将有 90% 的功能快速运行。但是，您的客户也会认为您已经完成了 90%，并且会想知道为什么要花 9 倍的时间才能完成工作。

如果您采用方法#1，那么我只会称其为原型并以这种方式对待它。将其表示为除此之外的任何东西只会导致以后的问题。快乐的一天场景只是工作的 10%。剩下的 90% 是让其他场景正常工作，让快乐的一天场景可靠工作。很难让非开发人员相信这一点。我通常在#1 和#2 之间做一些事情。我试图在识别用例和所有场景方面做得相当好。然后，我尝试找出对架构影响最大的场景并着手处理这些场景。

Answer 3

我建议对于 Tracer 项目符号，您可以使用阳性 + 阴性测试用例的组合

1. 积极的测试用例（这些将在您的用户故事/特性文档/功能规范中提及）
2. 负面测试用例（可以在 BAU 场景中预期的常见负面场景） （慎重考虑后可以省略罕见的业务场景。）

这些测试用例是使用 specflow 运行以自动化测试。

在您的测试用例中包含常见的否定场景可提供足够的信心，即可以使用底层代码完成后续开发。

在这里分享经验http://softwarecookie.wordpress.com/2013/12/26/tracer-bullet/