Tracer Bullet开发

Question

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

我可以看到两种方法：

1. 只是覆盖基本用例 写足够的代码来满足 用例我正在研究，然后回去 并充实所有的错误处理 后面。
2. 尽可能多地充实每个用例 可能，捕获所有异常并抛光界面，然后继续 下一个用例。

我倾向于第一种选择，但我害怕忘记处理一些异常，并在应用程序投入生产时让它咬我。或者留下不明确的“存根”错误消息。但是，如果我采取第二种选择，那么我认为我最终会在以后进行更多更改。

问题：
当使用示踪剂子弹开发时，您采取以下两种方法中的哪一种？为什么？ 或者，还有另一种方法我不知道吗？

Answer 1

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

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

你没有“抛光”每个用例的动机可能是进一步加速。问题是，这样做是否会危及1.以及客户是否真正对“未抛光”的结果感兴趣。即使不是，也能够迅速从客户那里获得反馈。

我说你的想法只要

• 你确保隐藏在“未抛光”的部分没有任何根本问题 - 这肯定会在错误处理中发生
• 您可以跟踪在问题跟踪器中稍后“擦亮”的任何内容，或者将TODO留在源代码中 - 并在用例工作后仔细检查
• 用例不是那么“未经修饰”，客户不能/不会给你有用的反馈

Answer 2

如果您采用方法＃1，您将有90％的功能很快运行。但是，您的客户也会认为您完成了90％，并且想知道为什么它会花费您9倍的时间来完成这项工作。

如果你采取方法＃1，那么我会称之为原型，并以这种方式对待它。要把它表示为更多，除了以后会产生问题。快乐的一天场景只占工作的10％。剩下的90％是让其他场景发挥作用，欢乐日场景可靠地运作。非开发人员很难相信这一点。我通常在＃1和＆amp;之间做一些事情。 ＃2。我试图在识别用例和所有场景方面做得相当不错。然后，我尝试确定最具架构影响力的场景并对其进行处理。

Answer 3

我建议使用Tracer子弹，你可以使用正面和负面测试用例的组合

1. 正面测试用例（这些将在您的用户故事/功能文档/功能规范中提及）
2. 负面测试用例（在BAU场景中可以预期的常见负面情景） （经过深思熟虑后，可以忽略罕见的业务场景。）

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

在测试用例中包含常见否定方案可以充分确信可以使用底层代码完成后续开发。

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