自从1983年开始编程以来，我不是新手，但我只对像Applescript，ARexx，HyperTalk和Bash这样的脚本语言有实际经验。
我编写脚本来自动化数据输入，批处理图像和转换文件格式。我涉足Processing，Ruby和Python。
我写的大多数程序都在200行以下，最多有10个函数。我希望将来能够编写更大，更强大的程序。我想改进我的做法，以避免造成脆弱，不可维护的混乱。我工作的编程环境（Script Editor.app和Text Wrangler.app）不支持自动化测试。
在我现在正在工作的规模和编写程序（不是OO）代码，是否适合编写单元测试，我理解的是：
测试个人的简短程序 在将它们组合成a之前的函数 功能齐全的大型项目。
在制作此规模的节目时单元测试是否值得与成本相比？
答案 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，单元测试可以让你分解你的程序的核心逻辑（这使你做更模块化的事情），并帮助你测试比你手动测试时更快的测试。毕竟，并非所有人都是唐纳德克努特。
请记住，我的答案是针对小功能，就像原来的海报一样