Question

我正在编写一个使用我创建的REST API的Django应用程序。目的是使用Web应用程序证明api用例。因此，在我看来，我使用python-requests库调用api，如下所示：

def my_view_method(request):
    if request.method == 'POST':
    form = MyForm(request.POST)
    if form.is_valid():
        data = form.cleaned_data
        data_to_post = {
            'fieldA': data.get('fieldA_in_form'),
            'fieldB': data.get('fieldB_in_form'),
        }
        post_url = "http://%s/%s/" % (request.get_host(), 'entries')
        logger.info("request api url: "+ post_url)
        r = requests.post(post_url, data=data_to_post)
        return HttpResponseRedirect('/')
    else:
        form = MyForm()

    return render(request, 'myview.html', { 'form': form })

我已经使用单元测试验证了使用有效数据POST到/ entries /会导致正确的数据库更新。

url = '/entries/'
#verify initial db state
data = { 'fieldA': value1, 'fieldB': value2 }
response = self.client.post(url, data, format='json')
# verify db was updated

在我的功能测试中，我使用LiveServerTestCase并与表单进行交互。当测试提交表单时，浏览器选项卡在标题中显示“正在连接...”并且测试用例挂起。当我直接与数据库交互而不是使用请求调用api时，情况并非如此，因此必须是延迟的来源。

LiveServerTestCase的工作原理是什么，我在这里不理解？

Answer 1

可能是LiveServerTestCase服务器一次只能处理一个请求吗？所以它挂起是因为它无法处理来自请求内的请求？

The source说它会“一次处理一个请求”，但话又说“没有阻塞”，所以这是不明确的......

我认为你最好放弃LiveServerTestCase而只是滚动你自己的测试跑步者。您可以使用setUp在单独的进程中启动runserver，并使用tearDown重置数据库（manage.py flush？）。如果你想使用测试数据库，你可以使用不同的settings.py，或者只是在测试期间将“真实”数据库移开...

Answer 2

请求在测试完成后挂起，因为您通过requests库而不是正式测试客户端here提出请求。

你甚至不需要这样做，直接测试API而不是通过Django启动Web服务器更有意义。

这是文档here

中对LiveServerTestCase的描述

LiveServerTestCase在后台启动一个实时Django服务器设置，并在拆解时将其关闭。这允许使用自动化测试客户端，例如Selenium客户端，以执行a 浏览器内部的一系列功能测试并模拟真实用户动作。

如果您想测试API本身，则无需为Django应用程序注册。

一种测试方法我喜欢关注这样的问题是组件集成方法，在Wikipedia here上有所描述。

在这个例子中，我们将与服务层（API）分开测试Django应用程序（前端）。在测试前端时，您仍然可以使用API，但存在分离以定义编写测试的方式。

由于API是Flask应用程序，我会使用内置于here所述的测试工具中的Flasks。

API与Django无关，是的，它被Django应用程序使用，并且该应用程序对该API有很强的依赖性，但您希望专门测试API本身。

为了帮助进行UI测试，您可以将API用作测试夹具/ setUp例程的一部分，以避免使用UI添加执行所需的任何测试数据。但是，如果您想要测试API本身，那么由于上述问题，通过Django客户端进行测试将无法正常工作。

LiveServerTestCase在django视图中挂起在python-requests后调用

2 个答案: