JUnit自动化测试脚本测试？

Question

我最近加入了这个目前正在工作的组织，该组织要求我管理一个项目，以重新考虑，扩展和维护用java编写的现有自动化测试框架，该框架使用关键字驱动框架和RFT。尽管我已经转向敏捷管理，但我一生都是一名开发人员。根据习惯，我在编写源代码之前编写单元测试来测试行为。该框架没有一个单元测试。我的第一直觉是“单元测试在哪里？”我知道我可以为测试框架类编写单元测试。在这里讨论时，提出编写测试框架或脚本的单元测试可能是浪费时间。我外交上不同意。

问题1：我的直觉可能是错的吗？你有什么建议可以帮助我打击我的案子。

问题2：这可以递归吗？编写测试和测试等测试。什么时候停止编写单元测试？是否存在测试测试器递归的概念？

我再次参加单元测试但从未遇到过这种情况。我从研究中找不到这个话题。

修改

谢谢大家的有趣回应！毫无疑问，单元测试肯定会写完！最优先考虑的是我们自己编写的框架类和方法，这些类和方法最常使用，并且具有较高的ROI和较高的失败惩罚。计划是逐步和逐步实现整个项目（java）的高水平代码覆盖率

Answer 1

如果您的组织编写了此测试框架，那么您应该对其进行单元测试。如果您使用现有的测试框架（例如JUnit），那么我就不会对其进行单元测试。将测试留给测试框架的创建者。

底线：你写了它，你测试它。

Answer 2

在Software Engineering radio对Kent Beck进行了非常好的采访，在那里他解释了他何时编写测试，何时进行TDD等的哲学。

他说，当他写一个探索性的代码，不会被共享的代码或不会持续的代码，一个尖峰解决方案时，他不会编写测试。其余的时间他都在写测试。

要回答您的问题，请问自己一个问题。如果你有测试，它会帮助你重构，扩展，维护这个框架吗？如果是，请编写测试。

1）通常，良好实践建议您在重构之前编写测试（以确保行为不会改变），或者在执行新代码（标准TDD）之前。

2）是的，这可以递归，但你只有很多时间，所以你必须考虑你为项目带来的额外价值所花费的精力。

编写单元测试可以帮助您更好地理解现有代码。就个人而言，我会写测试。

Answer 3

问题1：我的直觉可能是错的吗？你有什么建议对我的案子有所帮助。

你的直觉没有错。例如，如果您的测试框架存在错误，则可能会跳过测试错过错误。

问题2：这可能会递归吗？编写测试和测试等测试。什么时候停止编写单元测试？是否存在测试测试器递归的概念？

没有。因为测试用例应该是如此简单，以至于bug无法经受审查。每个测试都应该是微不足道的，或者被测试的类需要重构。显然，有时这说起来容易做起来难。

我会检查测试框架并在故障真正伤害的地方添加测试。

Answer 4

要测试某些东西，你需要一个参考，比较结果。对于框架或脚本，生产代码可以用作参考 - 除非版本不兼容：如果所有测试都通过框架N和框架N + 1，那么没有[可见]回归，所有应有的限制（提供足够的报道......）。这就是编写测试框架或脚本的单元测试可能被认为是浪费时间的地方。

现有框架在大多数情况下可能都有效，因此花时间将其置于单元测试之下可能是一种浪费。与任何软件一样，在添加新功能时编写单元测试，或者在重新编写代码的某些部分时将会很有帮助。

我通常不会为我的测试程序编写单元测试，或者只针对自动化测试有价值的特定部分。我将它们与生产代码一起使用，将每个代码作为另一个的脚手架。

Answer 5

另一件需要考虑的事情是自动化测试本身正在测试自动化测试框架。也就是说，如果你打破框架，测试本身应该失败。鉴于此，投资编写框架本身的自动化单元测试可能没有意义。