QA测试而使用API是一个好主意还是坏主意？
我们正在从头开始开发一个应用程序，并且一直在创建后门 API 来简化 QA 的工作。这些后门程序可以做很多事情，例如更改服务器的日期以模拟时间的进展等。我对此很复杂。这些后门的数量几乎可以与生产中使用的真实API相媲美。
这是推荐的方法吗？这样做的明显好处是它使QA的生活必须更轻松。我可以看到这样做的许多缺点，例如维护这些测试 API 的功能，确保这些后门 API 不会在生产中公开。
如果其他人使用了这种方法，那么有哪些好的方法可以确保这些 API 不会在生产中公开？
对于那些反对这种方法的人，是否有其他选择可以使QA的工作更容易？
谢谢
如果它不会导致QA遗漏问题，这是一件好事;如果你将来可以让他们的工作更轻松，而没有成本，那就去做吧。
但是，通常每当您测试一个 API 但使用另一个 API 时，您实际上并没有测试即将投入生产的真实 API。 如果QA对普通API有黑客攻击，他们也应该测试黑客和现实世界之间的差异。
在这种情况下，听起来他们有帮助程序方法来修改状态，以启用测试。 如果没有一个好的方法可以做到这一点，否则他们正在做的事情可能是非常合理的......或者，至少，可能有更好的方法来花时间改进事物。
但总的来说，它是否经常（反复）导致他们错过他们应该抓住的错误？
您使用什么构建系统？
对于任何具有任何时间/调度逻辑的软件，我认为使用名为"currentTime（）"的方法添加一个名为SystemClock的类非常重要。
在我们的 Android 项目中，我们从 Gradle 变量注入开始时间，然后我们可以确定代码不可能随着时间的转移而投入生产（因为该变量仅为调试版本定义）。
对于我们的iOS版本，我们能够使用扩展。这确实是一个很好的方法，因为它只编译到测试范围内。然后，它将 getCurrentTime 方法替换为移位方法。
你在Java世界中的另一个选择是方面。它们可以方便地在测试版本中执行生产中不存在的混合。