我的应用程序有一个React前端和ASP.NET核心Web API后端。我已经用react-testing-library构建了一些单元测试（即排除fetch()）。现在我想做一个集成测试，通过HTTP调用真实的的后端API。有很多独立的API测试工具可以做到这一点，但我仍然没有测试React组件和服务器之间的接口。有什么理由我不应该简单地编写jest测试，而不是stub out fetch()，并实现真实的的端到端测试？这对我来说似乎很明显，但我还没有看到任何文章讨论过它。
fetch()
bnl4lu3b1#
FWIW在进行了最初的几次测试之后，它似乎是一个非常成功的方法。我已经能够“几乎”远程控制UI（我的意思是它实际上并没有在浏览器中运行，而是使用了我的React组件），而无需学习或设置selenium。最头痛的是JSDOM的fetch实现（在他们的辩护中可能不打算做这种事情）。我遇到了很多关于cookie和CORS的问题，所以我使用了node-fetch，这让我对我生成的HTTP请求有了更多的控制。
uttx8gqw2#
是的，你可以用RTL做你所建议的事情（不是模拟fetch并攻击你的实际后端）。不过，希望你确实有一个测试数据库，这样你就不会弄乱你的生产数据。您的问题似乎可以互换使用端到端和集成，这并不罕见。“一体化”是广泛的，可以发生在不同的层面：
fetch
您可以调用最后两个端到端，只要您意识到RTL并没有为您提供浏览器自动化库的真实性保证，尽管user-event包可以提供帮助。尽管用例可能会鼓励您这样做，但作为一个经验法则，我建议主要将RTL用于前端代码，可能集成多个组件，但后端被嘲笑。如果你想做API测试（同样是不同程度的深度），最好为堆栈的那部分单独编写Jest/supertest测试。如果你想做端到端的测试，我建议不要模仿任何东西，而是使用像Playwright这样的浏览器自动化库。这些测试不需要很深，只是作为对其他测试的安全检查。“带有unmocked后端的RTL”模式并不是完全错误的，并且可能很适合某些情况，但总体上感觉不如上述模式理想。
2条答案
按热度按时间bnl4lu3b1#
FWIW在进行了最初的几次测试之后，它似乎是一个非常成功的方法。我已经能够“几乎”远程控制UI（我的意思是它实际上并没有在浏览器中运行，而是使用了我的React组件），而无需学习或设置selenium。
最头痛的是JSDOM的fetch实现（在他们的辩护中可能不打算做这种事情）。我遇到了很多关于cookie和CORS的问题，所以我使用了node-fetch，这让我对我生成的HTTP请求有了更多的控制。
uttx8gqw2#
是的，你可以用RTL做你所建议的事情（不是模拟
fetch并攻击你的实际后端）。不过，希望你确实有一个测试数据库，这样你就不会弄乱你的生产数据。您的问题似乎可以互换使用端到端和集成，这并不罕见。
“一体化”是广泛的，可以发生在不同的层面：
您可以调用最后两个端到端，只要您意识到RTL并没有为您提供浏览器自动化库的真实性保证，尽管user-event包可以提供帮助。
尽管用例可能会鼓励您这样做，但作为一个经验法则，我建议主要将RTL用于前端代码，可能集成多个组件，但后端被嘲笑。
如果你想做API测试（同样是不同程度的深度），最好为堆栈的那部分单独编写Jest/supertest测试。
如果你想做端到端的测试，我建议不要模仿任何东西，而是使用像Playwright这样的浏览器自动化库。这些测试不需要很深，只是作为对其他测试的安全检查。
“带有unmocked后端的RTL”模式并不是完全错误的，并且可能很适合某些情况，但总体上感觉不如上述模式理想。