只是想知道 TDD/自动化单元测试的利弊，并寻找社区对专业开发人员编写不支持单元测试的应用程序是否可以接受的看法？
问问题
138 次
3 回答
2
我敢打赌我会为此得到-1 -ed，但我仍然说：如果你有其他措施来确保质量，包括避免回归、程序验证、程序验证，那么 没有。
唯一的问题通常是人们除了单元测试之外没有任何其他工具来实现这一点。
如果您已经正式测试过模型（有一个工具，可以实际测试它，或者它以确保其有效的方式构建），并且您已经正式测试了确保实际运行的软件符合该模型的方法，那么没关系。
示例：如果您确定，您用 ruby 编写的代码将按照您的预期运行（因为您或其他人测试了 ruby 解释器并且它没有错误，或者您只使用了已知功能的子集）安全）然后就可以了。通常，我们以这种方式信任 C 编译器和 CPU。
此外，如果一个程序只使用一次，则不存在回归问题！如果我用 bash 编写一个单行代码，它会为我计算一些东西，我可能会先在假数据上手动测试它，然后在真实数据上运行它——无需编写自动化测试。
如果你承担责任，你也可以接受假设：我通常假设，eclipse 非常擅长创建 setter 和 getter，我不测试这些。另外，我假设，如果 Java 7 中的 Java 集合类有任何问题，现在它已经出现了。但万一有麻烦，那是你个人的麻烦。不要责怪任何人。
就个人而言，我很少对某些代码使用单元测试，因为我正式测试它们时它们仍然是一张纸上的流程图，并且我确保我只使用已知在这种情况下工作的语言/库的子集。此外，我从来没有在没有同行评审的情况下发布代码。不过，如果有人对它们进行验收测试，有时会更好......
于 2012-08-05T12:56:12.937 回答
1
它是由你决定。这个问题本质上更具哲学性。
单元测试只是帮助你的工具。您可以选择忽略它们。但是，如果您要从事一个不简单的项目，我建议您使用单元测试。
是的，他们也需要时间来写作。但最终，如果进行任何重构或需要更改代码的某些部分，您将节省很多。
于 2012-08-05T12:53:58.837 回答
1
一如既往：这取决于。
一般来说，单元测试是一件好事：它们捕捉到一整类错误，验证代码的特定部分在给定情况下是否按预期工作，并且在出现问题时更容易追踪错误。因此，除非您有充分的理由不这样做，否则您应该编写单元测试。
不编写单元测试的充分理由包括：
- 对结构糟糕且因此难以测试的代码库进行相对较小的更改（通常，原因是关注点分离很少，如果不对代码库本身进行侵入性更改，就无法隔离可测试单元进行测试）。
- 问题域的性质使代码本质上是不可测试的。这种情况很少见，但确实会发生——例如，很难为绘制 GUI 的例程提出有意义的单元测试：您必须将其渲染到模拟表面，然后检查单个像素，但是您' 还必须模拟所有影响布局决策的参数等；虽然这在理论上是可能的，但通常不值得付出努力，在这种情况下应该选择手动或半自动测试。
- 该项目是一个很小的一次性程序，范围如此之小，生命周期如此之短，以至于从单元测试中获得的好处（增加可维护性，降低复杂性）是微不足道的。但是请记住，软件的寿命往往比它设计的要长，你一次性的一次性脚本很可能最终成为公司流程的关键任务部分。
于 2012-08-05T12:55:51.217 回答