API接口测试代码应当存放在前端还是后端代码库？

这个问题是「Where to write tests for a Frontend/Backend application?」的重复问题，但我希望尽可能获取更多相关信息。

假设你正在开发新的API路由/get_something，需要对该端点进行测试以验证其功能正常。

我们假设该端点是正式生产环境端点，开发复杂度较高：需要特定的身份认证，输入参数有明确要求且必须按指定格式序列化，这意味着简单的http.Get()调用无法满足需求，你需要借助专门的函数（例如client.BuildGetSomethingRequest()）来发起调用。

无mock的测试逻辑应当如下：

• 传入不同参数发起API请求
• 断言返回输出与预期结果一致

此处的核心疑问是该组件的测试代码应当存放在哪里？

如果你将测试写在后端（即API路由所属的代码库），相当于你为该API路由实现了一套客户端调用逻辑，后续开发前端时还需要重复编写相同的客户端代码。

另一种可选方案是在前端代码库中对该API路由进行功能测试，这样你只需要编写一次请求构建代码（例如client.BuildGetSomethingRequest()），同时还能验证前后端交互是否正常。

我个人更倾向于第二种方案，但这种方案要求开发者在两个代码库之间切换，在一个组件中编写代码、在另一个组件中编写对应的测试也显得有些奇怪。

此外，如果前后端使用相同的开发语言（Javascript），两者耦合的设计是合理的，但从微服务架构的角度来看这种做法并不规范。

大家有什么看法呢？

谢谢。

回答 #

测试的存放位置本质上和测试的定位强绑定，不存在非A即B的绝对最优解，更合理的做法是按测试目的拆分，同时通过工程化手段解决你提到的重复代码、跨库协作、架构合规的问题。

1. 后端必须保留独立的API集成测试

API作为独立的服务单元，本身不应该和前端实现强绑定——你无法保证这个接口后续只会被当前前端调用，可能会有移动端、第三方服务、内部其他微服务的调用需求。后端侧的测试核心覆盖接口本身的正确性：参数校验逻辑、鉴权规则、业务逻辑、异常分支处理等，这些测试完全不依赖前端代码，是API上线的必要校验条件。

你担心的「重复编写客户端请求代码」的问题可以通过公共契约方案完全解决：

• 如果前后端都用JavaScript，直接把请求构建、参数序列化、类型定义抽为独立的npm包，后端测试和前端业务代码共同依赖该包即可，无需重复开发。
• 如果前后端技术栈不同，可以先定义OpenAPI（Swagger）接口规范，通过工具自动生成多语言的客户端SDK，从根源上避免重复编码。

2. 前端侧保留对应类型的测试即可

你提到的放在前端的测试，本质是前后端集成测试或端到端（E2E）测试，这部分确实可以放在前端仓库，它的定位和后端测试完全不重叠：后端测试验证API本身的正确性，前端的这类测试验证「前端调用API的逻辑符合预期，前后端交互没有问题」，两者覆盖的场景没有冗余。

跨仓库切换的问题可以通过CI流水线解决：配置后端代码提交后自动触发前端的集成测试，前端API调用逻辑变更后也可以触发后端测试用例的执行，无需开发者手动切换仓库验证。

3. 微服务架构下的适配

这种拆分完全符合微服务架构的规范：API的契约是公开的，公共SDK是契约的具象化实现，前后端都基于契约开发和测试，不存在耦合问题。就算后续有其他调用方接入，也可以直接复用公共SDK和契约规范，不需要调整现有逻辑。

内容的提问来源于stack exchange，提问作者solidak