单元测试绝对是值得付出努力的。不幸的是，您选择了一个困难的(但不幸的是常见的)场景来实现它。

从单元测试中获得的最大好处是从头开始使用它——在一些精选的小项目中，我有幸在实现类之前编写单元测试(此时接口已经完成)。通过适当的单元测试，您可以在类还处于婴儿期时就发现并修复它们，而不是在将来毫无疑问会集成到复杂系统中的任何地方。

如果您的软件是完全面向对象的，那么您应该能够在类级别上添加单元测试，而不需要太多的努力。如果您没有那么幸运，您仍然应该尽可能地尝试合并单元测试。确保当你添加新功能时，新部分都有清晰的接口，你会发现单元测试让你的工作变得更容易。

当你说“我们的代码库不适合简单的测试”时，这是代码气味的第一个迹象。编写单元测试意味着您通常以不同的方式编写代码，以使代码更具可测试性。在我看来，这是一件好事，因为多年来我在编写代码时看到我必须为其编写测试，这迫使我提出更好的设计。

单元测试的一个好处是，它们可以作为说明代码行为方式的文档。好的测试有点像参考实现，团队成员可以通过查看它们来了解如何将他们的代码与您的代码集成。

单元测试的全部意义在于使测试变得简单。这是自动的。“make test”就完成了。如果您面临的问题之一是难以测试代码，那么这就是使用单元测试的最佳理由。

根据我的经验，在复杂的软件环境中，单元测试和集成测试是“必须的”。

为了说服团队中的开发人员编写单元测试，您可能需要考虑在开发环境中集成单元测试回归分析(例如，在您的日常构建过程中)。

一旦开发人员知道如果单元测试失败，他们就不必花那么多时间调试它来发现问题，他们就会更有动力去编写这些测试。

这里有一个工具可以提供这样的功能:

单元测试回归分析工具

Unit Testing is one of the most adopted methodologies for high quality code. Its contribution to a more stable, independent and documented code is well proven . Unit test code is considered and handled as an a integral part of your repository, and as such requires development and maintenance. However, developers often encounter a situation where the resources invested in unit tests where not as fruitful as one would expect. In an ideal world every method we code will have a series of tests covering it’s code and validating it’s correctness. However, usually due to time limitations we either skip some tests or write poor quality ones. In such reality, while keeping in mind the amount of resources invested in unit testing development and maintenance, one must ask himself, given the available time, which code deserve testing the most? And from the existing tests, which tests are actually worth keeping and maintaining? See here