可以避免测试基类吗？

我有一个带有大量“元编程”的基类，以使其具有相当通用的灵活性/抽象性。

在基类中，我确实有很多使用通用方法的子类，并且有面向行为的单元测试，涵盖了每个子类中的所有情况。

可以跳过基类测试吗？

为了验证您是否有足够的测试，您可以检查代码覆盖率以及由测试引起的分支覆盖率（可以使用覆盖率工具，也可以通过查看代码路径或调试器来手动进行）。

如果得出结论，则子类的测试为您的基类代码提供了足够高的覆盖率，那么添加更多的测试显然不会给您带来太大的好处。另一方面，如果存在代码路径，则只能通过直接使用基类添加特定的测试来进行测试，那么您应该走这条路线。

“直接测试您的基类”的另一个可能原因是您要“单独”测试该类的特定功能。有时，直接为特定方法设计测试用例会更容易，而不是仅通过调用使用该方法的子类的方法来间接测试该方法，而不是仅间接测试该方法。

请注意，如果您有一个通用基类，其典型用法是为其派生一个子类，则您的基类可能是抽象的。因此，为了测试此类，您无论如何都需要进行派生。对于这种情况，当然，直接测试“基类”可能意味着要添加一个特殊的派生类，仅用于测试目的。

创建自动化测试是为了给程序员带来好处，而并不是为程序员提供服务。

我们进行了测试，以提高我们的生产力，并减少客户抱怨的“问题”数量。

因此，假设您具有面向行为的单元测试，涵盖了每个子类中的所有情况，那么直接测试基类对您的客户没有好处。这可以被确认通过在基类中改变了一些代码，如果测试失败看到，如常见的了一行代码，或添加一个“不”到“if语句”。（仅检查测试所覆盖的每一行代码还不够好。）

然后，我们要问测试是否会使您的工作效率更高。这可以通过几种方式发生。

• 让您更清晰地思考代码-在这种情况下，编写代码是不太可能的。
• 让您单独测试基类中的某些代码，因此可以更快地对其进行调试，在这种情况下，由于代码已经在工作，因此再次调试的可能性很小。
• 让您可以在基类中更改代码，而不必了解子类中逻辑的详细信息–也许是在重构代码？

因此，鉴于子类正在工作，我看不出为基类编写直接测试有任何意义。 到今天为止，在早期阶段编写这些测试不会有任何好处。