Hoje em dia, comecei um novo projeto e tentei várias coisas que não conhecia antes, como plim, stylus, coffee e sqlalchemy. Mas o que me prendeu foi que não consigo configurar meus unittests no início.
Costumávamos executar webtests com paste, tratando-o como o testapp padrão. Podemos fazer o login como um usuário passando extra_environ={'REMOTE_USER': 'imom0'}para ele. Por exemplo, testamos um formulário django desta forma antes:
app = TestApp(extra_environ={'REMOTE_USER': 'imom0'})
resp = app.get('/my/precious/')
csrf_token = resp.form['csrfmiddlewaretoken'].value
resp = app.post('/my/precious/', {'csrfmiddlewaretoken': csrf_token, ...}, extra_environ=...)Tão distorcido, não é?
Não podemos usar django testapp para essas informações de autenticação extra manipuladas por nosso testapp de pasta personalizado. Por outro lado, ao usar o testapp de pasta para testar flask e wtforms (flask-wtf), a sinalização WTF_CSRF_ENABLEDparece ser Truepara sempre, você não pode obter nada além de 403s .
Acho melhor usar o testapp do flask ou o testapp do django , então o problema gira em como definir um ambiente extra para eles.
Depois de visualizar o código-fonte do testapp de pasta encapsulada, a funcionalidade foi adicionada por:
from appengine.utils import set_environ
# in __call__ of the wsgi application
set_environ(environ)Resumidamente, considero os aplicativos WSGI como coisas que podem ser chamadas que aceitam (environ, callback)como entradas e sempre retornam algo iterável .
Primeiro, apliquei um patch werkzeug._internel._get_environcom a adição de set_environfunção após a original. Mas a melhor prática é envolver o aplicativo wsgi com middleware.