在这种情况下，有两个HTTP微服务：
服务1呼叫服务2，要求它验证客户提供给它的令牌。
协议（“合同”）是服务2应回复200 OK和有关经过身份验证的用户的JSON内容。
在服务1中，如果收到回复200 OK，是否值得继续进一步验证回复？
例如，响应的JSON主体被解析为一个对象。检查该对象是否被正确实例化而不是设置为null是否有价值？或者应该留给集成测试？
答案 0 :(得分：0)
严格来说，200仅表示请求已成功处理。从业务角度来看，这与呼叫的实际结果无关。
您实际上依赖于＆＃34的惯例;如果用户未经过身份验证，我们将抛出异常或以其他方式使呼叫失败＆＃34;，以对用户进行身份验证。
根据惯例，您可以想象有一个用户未经身份验证但仍然成功处理了呼叫的情况。
从这个角度来看，可能值得让service2返回一个响应，然后可以通过询问来关闭这个循环。
或者，您可以让客户端直接调用身份验证服务，检索令牌，然后将此令牌与任何其他请求一起呈现。这意味着service1不再需要知道调用者已经过身份验证。
问题是，每次是否在服务1中进行测试 收到回复
对不起，我似乎在某种程度上误解了这个问题的精神。
我有点困惑 - 你问的是，如果被测系统是service1，那么来自service2的任何响应是否也应该是该测试的一部分？
我想说你必须有一些测试可以证明sercvice2响应询问逻辑是正确的，但这可以在单元测试级别完成。我不认为你需要为针对部署的服务实例运行的测试执行此操作，这本质上更多地是关于边界而不是内部的服务行为。
答案 1 :(得分：0)
嗯，你的做法并不是那么糟糕！
某些HTTP状态代码是为格式错误的请求等保留的。但在您的情况下，您要求Service2返回令牌的信息！如果该令牌存在，则表明您已正确指定Service2必须返回200 OK。现在你只需要指定如果令牌不再有效或者它不存在会发生什么（或者两个案例都相同......）。如果您指定，Service2必须返回404 Not found，如果它不知道令牌或令牌已过期，那么（在大多数情况下）Service1不需要再继续！在几乎任何语言/环境中解析状态代码都很便宜，但是在成功和错误情况下强制内容的反序列化相比非常昂贵。身份验证需要很快 - 所以我在这里寻找状态代码！
关键是，必须在某处指定此行为！ （我们选择了昂首阔步的定义！）