Learn-json-web-tokens: 测试使用 JWT 的 API

好吧，我有一些可能有用的建议：

1. 在您的系统中设置一个 _test_ 客户端并在测试中硬编码一个令牌。 保持身份验证。
2. 运行测试时，请确保身份验证已关闭。 我想有不同的方法可以做到这一点。 例如，在Hapi 中，您可以省略默认身份验证方案，而仅在服务器实际运行时（但在运行测试时不能）设置一个。
3. 模拟堆栈，因此您只是对控制器逻辑进行单元测试，而无需通过系统发出请求。 但是在某些框架中它可能不可行。

我正在研究一些系统，我们选择了 (1)。 这些测试看起来更像是集成测试而不是单元测试，因为它们贯穿整个堆栈。 另一方面，测试和生产环境之间没有差异。

如果您想在代码中确定环境，您可以在运行测试时设置NODE_ENV=test （实验室中的fx. -e参数）。 但是，您应该意识到测试和生产环境不会有太大差异，否则您并没有真正测试生产环境。

@rhewitt22我们更喜欢@walling 描述的方法
（其中测试更类似于“集成”而不是“单元”测试）
正是因为这个原因。 你嘲笑的一切都是“_fake_”，因此你不知道“_real_”什么时候起作用（_所以更有可能是错误_）。

我们继承了 (_large_) 项目，其中人们_忘记_在更改方法时更新模拟，因此测试不能反映_现实_； _噩梦调试_！

总是问自己：“_（为什么）我们需要嘲笑这个吗？_”

如果您嘲笑某些东西是因为它不受您的控制，例如 3rd 方服务或网络设备，
这说得通。 但是，如果您正在嘲笑自己的堆栈_，您就会考虑到您可能会使事情变得过于复杂......

您_问题_中的线索是“ _API _”一词，这表明您不是在测试“单元”，而是（API）“_端点_”。

点击端点，如果你得到 401，你就知道你需要 _authenticate_！ （_好消息！您的应用按预期运行！_）

这是一个_working 示例_ 的测试，它确实您的需求_：
https://github.com/dwyl/hapi-auth-jwt2/blob/f17bac65d40b2a9154da84390b874cae4e1de192/test/test.js#L119 -L135

那么我推荐阅读：

• 何时模拟： https :
• 模拟不是存根： http :
• 微服务测试： http :
• 我什么时候应该嘲笑？ http://stackoverflow.com/questions/38181/when-should-i-mock

tl;博士

如果你_自己的_代码太复杂，你觉得_需要_模拟它，_首先简化你的代码_！！

此外，我们编写了hapi-auth-jwt2插件，以便其他人可以依赖我们的测试。 并发布了一个_线性可扩展_Redis 支持的示例： https :

_我们_仅在我们的测试“_感觉太慢_”时才进行模拟，否则我们_总是_在每次测试通过时_尽可能_使用尽可能多的堆栈（同时将依赖关系限制为仅 _essential_）。

如果您的应用程序功能的某个元素需要身份验证，为什么不将其用作_机会_来_行使_您的身份验证/验证方法？ 最终，了解您的 auth 的 _performant_ 对您的应用程序来说是 _good_ ，因为 auth/verify 是您堆栈中最大的瓶颈之一！ （即 _every_ GET/POST/PUT/DELETE _request_ 必须通过 auth/verify，所以它不应该花费超过几毫秒的时间......超过这个时间并且你的应用 _won't scale_！）

记住：不要_假设任何事情_并自己决定测试应用程序的意义。 如果有进行测试的“正确方法”，那么所有大学都会教授它……没有。 “最好的方法”是“_pragmatic_”方法； 做对你的项目有意义的事情。

希望有帮助。 如果没有，请让我们知道您卡在哪里！ ：+1：

谢谢你俩！ 这非常有帮助。 根据您的建议，我认为此设置适用于集成测试——我绝对想知道这些部分是否可以协同工作。

我只使用 oAuth 作为我的身份验证方法（没有用户名/密码）。 我有兴趣了解有关如何创建测试客户端的更多信息。 我知道我不想经历整个 oAuth 流程，但正如您建议的那样，硬编码一个我可以在测试中使用的令牌。 你能推荐任何可以帮助我围绕创建测试客户端的资源吗？

如果它有助于我当前的项目使用 SailsJS v11.0。 我有一个引导程序测试文件，它启动我的服务器并使用夹具创建/填充内存数据库。 这可能是创建测试客户端的合适位置吗？

再次感谢您——找到如此愿意分享知识的人真是太好了。

@rhewitt22好吧，在我的情况下，测试客户端就像创建一个使用正确的有效负载和密钥签名的非过期 JWT 令牌一样简单。 也许这有帮助。

在 OAuth 中，我认为这取决于身份验证流程。 也许您甚至可以创建具有特定权限且不会过期的最终访问令牌，因此您不必每次都经过流程。

如果该令牌在生产系统中也授予了很多权限，请注意在测试中硬编码非过期令牌的安全问题。 那么潜在的攻击者只需要这个令牌就可以访问。 您可能需要某种方式来授予对某些客户端的访问权限，并且在运行测试时，您可以授予对测试客户端或令牌的访问权限。 我希望这一切都有意义。

@walling

感谢您的建议！

我只是继续创建了一个假用户，跳过了 oAuth 流程，在我的测试中，并授予他们我在生产中使用的相同 JWT（带有到期）。 我所有的测试都通过了，我是一个非常快乐的露营者。

:smile: :smile: :smile:

我认为当我在我的应用程序上工作并查看开发服务器时，我将确保 oAuth 部分按预期工作。