我们的项目包含2600个类文件，我们决定开始使用自动化测试。
我们知道我们之前应该已经启动了这个2599类文件，但大型项目应该如何以及在何处开始编写测试？
选择一个随机课，然后去？
知道什么是重要的？有没有好的工具可供使用？
答案 0 :(得分：16)
在更改内容之前编写单元测试，以及遇到的每个错误。
换句话说，测试您当前正在使用的功能。否则，为所有类编写测试需要花费大量的时间和精力。
答案 1 :(得分：6)
开始为每个提交的错误编写测试（编写测试，观察测试失败，修复错误，再次测试）。还要先测试新功能（它们更有可能出错）。它在开始时会很慢，但随着您的测试基础架构的增长，它将变得更加容易。
如果您使用的是java 5或更高版本，请使用junit 4。
了解单元测试，集成测试和验收测试的区别。还要看看嘲笑。
答案 2 :(得分：3)
其他答案提供了有用的建议，但我错过了对基本原则的明确阐述：努力从您的努力中获得最大利益。在很大程度上使用单元测试覆盖大型遗留代码库需要花费大量时间和精力。您希望从一开始就最大限度地提高您的工作成果。这不仅可以在早期提供有价值的反馈，而且有助于说服/保持管理层和开发人员的支持，这些努力是值得的。
所以
答案 3 :(得分：2)
不要先尝试单元测试。进行涵盖大面积代码的系统测试（端到端测试）。为所有新代码编写单元测试。
这样，您可以使用系统回归测试来稳定旧代码。随着越来越多的新代码出现在代码中，没有单元测试开始逐渐消失。在没有系统测试的情况下编写旧代码的单元测试可能会破坏代码并且需要做大量的工作才能证明代码不是以可测试性为基础编写的。
答案 4 :(得分：2)
你可能会发现Michael Feathers的书Working Effectively with Legacy Code很有用。
答案 5 :(得分：2)
你现在已经相当沉闷了，但是编写测试可以支持你拥有的最关键的代码。例如，如果您的代码允许基于用户权限的功能，那么这是一个巨大的 - 测试。一个名称并将其写入日志文件的例程？没那么多。
“如果这个代码破了，它会吮吸多少”是一个很好的试金石。
“我们的内部维护屏幕在IE6上看起来很糟糕”是一个答案。 “我们向每位客户发送10,000,000封电子邮件”是另一个答案。
你会先测试哪些课程，呵呵。
答案 6 :(得分：1)
您可能会发现这本书具有相关性和趣味性。作者解释了如何完全按照你的要求去做。
答案 7 :(得分：0)
哦，还有一件事 - 单元测试数量不足比没有单元测试要好得多。如果你能做到的话，一次添加一些。不要放弃。