单元测试是否适合短程序

时间:2008-10-14 03:58:08

标签: unit-testing

自从1983年开始编程以来,我不是新手,但我只对像Applescript,ARexx,HyperTalk和Bash这样的脚本语言有实际经验。

我编写脚本来自动化数据输入,批处理图像和转换文件格式。我涉足Processing,Ruby和Python。

我写的大多数程序都在200行以下,最多有10个函数。我希望将来能够编写更大,更强大的程序。我想改进我的做法,以避免造成脆弱,不可维护的混乱。我工作的编程环境(Script Editor.app和Text Wrangler.app)不支持自动化测试。

在我现在正在工作的规模编写程序(不是OO)代码是否适合编写单元测试,我理解的是:

  

测试个人的简短程序   在将它们组合成a之前的函数   功能齐全的大型项目。

在制作此规模的节目时单元测试是否值得与成本相比

9 个答案:

答案 0 :(得分:7)

是。任何长于零线的东西都可以进行单元测试 - 通常效果很好。

答案 1 :(得分:4)

我会看一下回归的可能性,而不是代码行数。如果您的程序将存在很长时间并且可能被重构或以其他方式修改,那么单元测试可能是有意义的。如果代码是一次性的或永远不可能被修改,那么单元测试可能是不值得的。

答案 2 :(得分:4)

今天它是一个小项目,明天它是您企业基础设施的核心。从右边开始,立即获得100%的代码覆盖率。

答案 3 :(得分:3)

单元测试有两个目的;最明显的是测试代码以确定它正在做它应该做的事情。但另一个更有用的目的是隐式文档;如果你明确地对特定行为的代码进行单元测试,那么即使非显而易见,也可以预见到这种行为。

考虑简单的加法运算符。直截了当,对吧?那么,当添加两个有符号整数时,预期的行为是什么,这两个整数都是>比MAXINT / 2?是MAXINT,还是负数?

记录所有这些东西有时可能很笨拙;不是说不应该这样做,但经验表明它经常无法完成。然而,对上述案例进行测试的明确单元测试消除了所有疑问;除了为回归提供有效目的外,该行为并未随时间发生变化。

答案 4 :(得分:2)

总之,你会知道你在几个月内添加新功能时没有破坏任何现有功能....

只是对一段代码进行一组测试的众多正值之一。

答案 5 :(得分:1)

如果代码逻辑上可以分成更小的单位,那么单位测试是合适的。如果代码不能合理地划分为更小的组件,那么它就是一个单元,我认为在这种情况下,自动化单元测试和自动功能测试将难以区分。

答案 6 :(得分:1)

编写测试可能有助于验证函数的设计(API是否有意义),并有助于保护您免受将来的错误。单元测试也可以作为函数的契约,可以指示函数的使用方式和期望。

如果没有很多时间,只需通过阅读代码就可以清楚地看到简短的程序,如果彻底测试它可能没有多大帮助。否则,我必须同意我的同事们的观点,即单元测试有很多好处,即使对于小型项目也有帮助。

警告:以下链接可能不适用,但随后的讨论很好。

最近在博客圈内讨论了何时适合测试,特别是测试驱动开发(TDD)。您可能需要查看Roy Osherove撰写的一些文章,例如these three articles

答案 7 :(得分:0)

您需要编写单元测试的唯一时间是您关心程序的输出是否正确,并且将来会继续正确。

如果您的代码的正确性不重要,则无需进行单元测试。

答案 8 :(得分:0)

我必须偏离大多数答案。唐纳德克努特曾在一次采访中说过,当人们不确定自己在做什么或者在一个不太舒服的领域工作时,人们往往会测试大多数事情。

考虑到这一点,我说除了像 mcwafflestixlivejournalcom 这样的记录之外,如果你不是100%肯定你的代码,单元测试只会帮助你。以两个整数的加法运算符为例,如果我增加两个人的年龄,我不关心溢出。

OTOH,单元测试可以让你分解你的程序的核心逻辑(这使你做更模块化的事情),并帮助你测试比你手动测试时更快的测试。毕竟,并非所有人都是唐纳德克努特。

请记住,我的答案是针对小功能,就像原来的海报一样