9

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

我可以看到两种方法：

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

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

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

4

3 回答 3

13

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

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

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

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

  • 您确保没有任何基本问题隐藏在“未抛光”部分中 - 这肯定会发生在错误处理中
  • 您可以在问题跟踪器中或通过将 TODO 留在源代码中来跟踪您稍后必须“抛光”的任何内容 - 并在用例正常工作后仔细检查这些内容
  • 用例不是那么“粗糙”以至于客户不能/不会给你有用的反馈
于 2009-04-13T13:13:05.550 回答
5

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

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

于 2009-04-13T19:24:46.470 回答
0

我建议对于 Tracer 子弹，您可以使用阳性 + 阴性测试用例的组合

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

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

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

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

于 2014-01-12T15:18:04.393 回答