代码之家  ›  专栏  ›  技术社区  ›  Gavin

在测试/原型制作期间进行单元测试是个坏主意吗?

  •  20
  • Gavin  · 技术社区  · 17 年前

    15 回复  |  直到 17 年前
        1
  •  12
  •   Mark Seemann    17 年前

    简而言之,TDD对于测试版来说非常有价值,但是 可能 对于原型制作来说就不那么重要了。

    我认为区分测试版和原型非常重要。

    A. 测试版

    A. 原型 /概念证明是你构建的东西,一旦你从中得到了你想要的答案,你就会明确地把它扔掉。

    诚然,项目经理倾向于推动将原型用作生产代码的基础,但抵制这种做法非常重要。如果你知道这是不可能的,那么就把原型代码当作生产代码来对待,因为你知道这一点

    单元测试经常迫使你更深入地学习技术,而不是只遵循老路,所以可能感觉像是开销的东西实际上只是一个更深入的原型——一个通常更有价值的原型,因为它覆盖了更多的领域。

    就我个人而言,我认为对一项新技术进行单元测试是一个很好的学习工具。

    更容易

    xUnit Test Patterns

        2
  •  10
  •   user1228 user1228    17 年前

        3
  •  6
  •   Thomas Owens    17 年前

        4
  •  5
  •   cwap    16 年前

    你们中有谁也发现,如果你正在制作原型/构建测试版,TDD可能会很麻烦?

    我有。.无数次:)

    TDD是更自然地与规范更固定的东西结合在一起,还是与开发人员在语言和技术方面有更多经验的地方结合在一起?

    还是我做了根本性的错误?

    看起来不是这样:)你刚刚看到TDD由金树以外的其他东西组成。。

        5
  •  4
  •   S.Lott    17 年前

    很好。你 花很多时间在测试上。这很重要,这就是你如何证明你的代码是正确的。“代码比测试少”是一个很好的基准。

    这意味着您正在编写有效的测试,以证明您对底层技术的期望。

        6
  •  4
  •   Gishu    17 年前
    • TDD或无TDD。“不得不花大部分时间更改测试而不是代码”表明要么规范发生了根本性的变化,要么你只是过度嘲笑自己,也就是“脆弱的测试”。我需要你更多的意见来进一步评论。

    运输原型会比你想象的更快、更难地咬你。相信我吧。

        7
  •  3
  •   Carl Manaster    17 年前


    所以没有必要进行测试。 但是!

        8
  •  2
  •   henrik    17 年前

    在敏捷开发中,有一个“尖峰”的概念——对解决方案或技术进行深入但狭义的调查。一旦你对事情应该如何运作感到满意,你就可以重新开始一个具有更高质量水平的新实现。

    被标记为“测试版”的软件存在一个陷阱——突然之间,你得到了一些不是作为应用程序重要组成部分用于生产的东西,而你没有时间重做它。这很可能会在以后回来咬你。原型应该只是一个原型——不多也不少。

        9
  •  2
  •   Jay Bazuzi Buck Hodges    16 年前

    我没有给你开处方,但我确实有诊断:

    • 如果你最终进入调试器,你应该进行更多的测试

    • 如果你想重构,但因为风险而不重构,你应该做更多的测试 。如果我要处理一些代码超过几个小时,我想重构以保持高速度。如果我对重构犹豫不决,那会损害我的工作效率,所以我尽我所能让重构变得安全和容易。再一次,一个好的测试选择正是我所需要的。

        10
  •  1
  •   ndp    16 年前

    对于纯粹的原型设计,正如人们所说,没有那么有用。但通常原型会包含后续应用程序的元素。

    你希望继续学习哪些坚实的概念?关键领域模型是什么? 围绕这些构建测试是有意义的。然后,它们为探索想法提供了坚实的基础。 通过使部分代码库稳固并经过测试,它允许您在原型上比没有测试时走得更远。

    这总是在选择正确的东西进行测试之间取得平衡。从你的描述中听起来,你一次采用了很多新东西——有时这可能太多了,你需要退一步来优化你的进度。

        11
  •  1
  •   Don Branson marios    7 年前

    我通常为这个原型代码做的是在没有测试(或测试不多)的情况下编写它,但在我的src/test/java下或我放置测试代码的任何地方完成工作。这样,我就不会无意中把它投入生产。如果有我喜欢的原型,那么我会在src/main/java(我的prod代码)中创建一些东西,并对其进行TDD,在添加测试时一次从原型中提取一段代码。

        12
  •  0
  •   Community Mohan Dere    9 年前

    我编写(并运行)系统I/O的自动化测试。系统的I/O取决于功能需求,当系统的实现发生变化时不会改变,因此我可以在不改变自动化测试的情况下重构实现: Should one test internal implementation, or only test public behaviour?

        13
  •  0
  •   Aaron Digulla    17 年前

    当我接触到一项新技术时,我通常会编写一些测试,作为原型的基础。这里的主要优点是,它允许我在小的、易于理解的部分习惯这项技术,并且我以唯一有效的文档形式记录我的进展:代码。

    现在,我的产品的设计会随着时间的推移而改变,但这些尖峰测试仍然有效:底层框架不会因为我现在追求不同的解决方案而改变。事实上,这些测试将允许我迁移到该技术的下一个版本,因为当我一直使用的假设之一发生变化时,它们会发出警报。否则,我必须保持当前版本,或者在任何升级时都要非常小心,因为我不确定它会破坏什么。

        14
  •  0
  •   Sam    17 年前

    在原型设计时,我会谨慎地拒绝TDD。主要是因为原型往往(但并非总是)演变成最终产品。如果你能确定原型一旦确立了它们最初的目的,就会被扔掉,那么你可能会有点松懈。然而,如果原型有可能演变成最终产品,或者部分代码将被移植到最终产品中,那么将努力遵循TDD原则。

        15
  •  0
  •   Todd    16 年前

    如果它实际上是一个原型,当你完成它时,你打算把它扔掉,那么就采取任何能让你度过这个阶段的路线。但是,问问自己,你的原型多久会被扔掉一次,而它们多久会潜入你的最终产品中?

    有一个很好的 presentation