我最近加入了我目前工作的这个组织，该组织要求我管理一个项目，以重构、扩展和维护一个用 java 编写的现有自动化测试框架，该框架使用关键字驱动框架和 RFT。尽管我已经转向敏捷管理，但我一生都是一名开发人员。按照习惯，我会在编写源代码之前编写单元测试来测试行为。这个框架没有一个单元测试。我的第一直觉是“单元测试在哪里？” 我知道我可以为测试框架类编写单元测试。在这里的讨论中，有人提出为测试框架或脚本编写单元测试可能是浪费时间。我在外交上不同意。
问题1：我的直觉会不会错？你有什么建议可以帮助我打官司吗？
问题2：这可以递归吗？为测试和测试编写测试等等。是否有关于何时停止编写单元测试的规则？是否有测试测试器递归的概念？
我再次支持单元测试，但以前从未遇到过这种情况。从我的研究中，我找不到太多关于这个主题的信息。
编辑
谢谢大家有趣的回答！毫无疑问，单元测试肯定会写出来！最高优先级将给予我们自己编写的最常用的框架类和方法，这些类和方法将具有高投资回报率和高失败惩罚。计划是逐步逐步实现整个项目（java）的高水平代码覆盖率
如果您的组织编写了这个测试框架，那么您应该对其进行单元测试。如果您使用现有的测试框架（例如 JUnit），那么我不会对其进行单元测试。将该测试留给测试框架的创建者。
底线：你写它，你测试它。
在软件工程电台对 Kent Beck 进行了一次很好的采访，他解释了他关于何时编写测试、何时进行 TDD 等的哲学。
他说，当他编写一段探索性的代码、不会共享的代码或不会持久的代码时，一个尖峰解决方案，他不会编写测试。几乎其他时间他都在写测试。
要回答你的问题，问自己一个问题。如果你有测试，它会帮助你重构、扩展、维护这个框架吗？如果是，请编写测试。
1) 通常，良好实践建议您在重构之前（以确保行为不会改变）或编写新代码（标准 TDD）之前编写测试。
2) 是的，这可能是递归的，但是您一天中只有这么多时间，因此您必须考虑为为项目带来的额外价值而付出的努力。
编写单元测试也可以帮助您更好地理解现有代码。就个人而言，我会编写测试。
问题1：我的直觉会不会错？你有什么建议可以帮助我打官司吗？
你的直觉没有错。例如，如果您的测试框架有错误，它可能会通过跳过测试而错过错误。
问题2：这可以递归吗？为测试和测试编写测试等等。是否有关于何时停止编写单元测试的规则？是否有测试测试器递归的概念？
不，因为测试用例应该非常简单，以至于错误无法通过审查。每个测试都应该是微不足道的，或者被测试的类需要重构。显然，有时这说起来容易做起来难。
我会检查测试框架并在失败会真正造成伤害的地方添加测试。
要测试某些东西，您需要一个参考，一个用来比较结果的东西。对于框架或脚本，生产代码可以作为参考 - 除非版本不兼容：如果所有测试都通过框架 N 和框架 N+1，则没有 [可见] 回归，都会受到限制（提供足够的覆盖范围......）。这就是为测试框架或脚本编写单元测试可能被认为是浪费时间的地方。
现有的框架可能在大多数情况下都有效，因此花时间对其进行单元测试可能是一种浪费。与任何软件一样，在添加新功能或返工代码的某些部分时编写单元测试会很有帮助。
我通常不会为我的测试程序编写单元测试，或者只为自动化测试有价值的特定部分编写单元测试。我将它们与生产代码一起发展，使用每个作为另一个的脚手架。
要考虑的另一件事是自动化测试本身正在测试自动化测试框架。也就是说，如果你破坏了框架，测试本身应该会失败。鉴于此，投资编写框架本身的自动化单元测试可能没有意义。