我应该在新项目开始时使用TDD吗?

时间:2012-03-30 16:52:13

标签: unit-testing tdd

我正在开发一个新的PHP项目,虽然我喜欢TTD,但我发现它似乎比在项目的这个阶段更有帮助。

我开始编写单元测试但是现在我更深入地研究了一些应用程序功能的原型,我发现自己重写了核心框架的部分内容以及编写测试。我似乎花了很多时间重写测试,也许我应该等到我处于项目的alpha / beta阶段。

我是否应该从头开始编写单元测试,即使我很可能不得不重写它们?

5 个答案:

答案 0 :(得分:3)

如果您要使用TDD,最好先使用它。

如果您认为这是正确的选择,那就使用它,或者当您决定将来使用它时,您可能会感到头痛。

答案 1 :(得分:3)

是的,这是理解您的系统并创建可靠API的最佳方式。

听起来你需要将测试提升到更高的水平。不要测试单个方法,测试功能单元。 The more recent buzzword is BDD or Context/Specification但事实并非如此,因为我还没有见到一位至少没有朝这个方向努力的tdd从业者。

答案 2 :(得分:1)

当然你要改写它们,事情会发生变化。

如果你做了一个完整而彻底的需求分析,那么事情就会发生变化(当你追求那种嵌合体时,更有可能发生变化)并且你将不得不重新分析。

但是如果你直接潜入并编写了一些代码并对一些可交付成果进行了分类,那么你将没有有用的分析,没有测试,然后整个销售部门会动手,因为交付=可销售。

迭代,编写测试,实现它们,看看你下一步去哪里。在您拥有一些软件之前,TDD或经典的水下降,需要大量的工作。

预先做好第二次工作,而不是大量使用,反正永远不会发生。

也许你需要更多的概念证明或故事登记,或神灵禁止分析,但所有潜水都是在仪表板上放置表情符号,你唯一可以获得的信用是当轮子脱落时,nads和次级风格的技术债务危机。

答案 3 :(得分:1)

  

我发现它似乎比帮助更有阻碍   这个项目的这个阶段。

为什么?你能更客观地确定你的担忧吗?

  

现在我更深入地研究了一些应用程序的原型   功能,我发现自己重写了核心的点点滴滴   框架以及编写测试。它看起来就像我   花更多的时间重写测试,我可能会等待   直到我处于项目的alpha / beta阶段。

  • 在进行原型设计时不要使用TDD。原型是为了获得知识......快速...在时间盒中最好。一旦消除了不确定性,就扔掉原型。这次用TDD重新开始。
  • 您的测试是否因为您现在有更好的洞察力而发生变化?或者是测试与实现相结合的情况(知道如何实施测试主题与提供的服务)?前者是不可避免的,除非你有远见卓识。要求改变,测试改变。后者是一种气味......可以通过专注于什么而不是如何?来避免。
  • 等到你的产品/应用程序稳定的问题是......你可能最终拖延或者你可能最终得到一个难以测试的设计。这将使编写测试(后来)比以前更难。 如果您在可测试的代码基础上以较小的增量工作,TDD会变得更容易。测试也是一个安全网,可以帮助您自信地进行更改并提供即时反馈。

答案 4 :(得分:0)

  • 是的,我认为从一开始就开始编写测试非常重要。 TDD(测试驱动开发)不仅仅是单独测试各个类。它应该指导您在设计阶段做出的决策。

  • 当您首先编写测试时,您将更好地了解您的问题。你说你以后可能会重写它们。如果是这种情况,那么这可能意味着您将更好地了解您的系统,这是一件好事。然后,您可以通过实施进一步的测试或重新分解现有测试来重新设计您的系统。

  • 这可能是浪费时间,但并不是因为你对你正在进行的系统有了更好的理解。

  • 我正在阅读的其中一本书(以测试为导向的面向对象的软件)提到了“行走的骷髅”概念。它建议您应该使用TDD来开发最小的工作解决方案,即使它非常基础。

  • 另一个要点是,您应该从一开始就尝试自动部署。这不是一个单元测试,但它是一个部署测试,即使不比单元测试更重要,也是如此。如果您在项目开始时进行此类测试,则在发布日期附近不会遇到意外问题。您还可以更好地了解系统的不同组件如何组合在一起。