2011-06-16 14 views
9

Acabo de actualizar a Django 1.3. Mi suite de pruebas ahora muestra un montón de advertencias inútiles como esta cada vez que compruebo que una URL determinada es 404. No hizo eso en Django 1.2.¿Evita las advertencias en 404 durante las pruebas de django?

Por ejemplo, supongamos que tenemos puntos de vista y las direcciones URL cableados de tal manera que esta prueba pasa:

def test_foo(self): 
    response = self.client.get('/foo/bar/') 
    self.assertEqual(response.status_code, 200) 
    response = self.client.get('/foo/bar2/') 
    self.assertEqual(response.status_code, 404) 

Aunque se supera la prueba, el 404 (que esperamos) desencadena una advertencia en la consola:

.ADVERTENCIA No encontrado:/foo/bar2/

Esto es solo ruido inútil; Tengo alrededor de 30 de ellos en uno de mis conjuntos de prueba actuales.

¿Hay alguna manera de silenciar esos solo durante las pruebas? Me gustaría dejarlos encendidos durante el funcionamiento normal. Y no creo que quiera filtrar todas las advertencias del registrador 'django.request'.

Respuesta

11

La advertencia proviene de aquí: http://code.djangoproject.com/svn/django/trunk/django/core/handlers/base.py

Lo que se quiere hacer es establecer el umbral de registro del módulo 'django.request' a algo por encima ADVERTENCIA (por ejemplo ERROR) al comienzo de la prueba, y luego establecerlo de nuevo después.

intentar algo como esto:

import logging 

#before tests 
logger = logging.getLogger('django.request') 
previous_level = logger.getEffectiveLevel() 
logger.setLevel(logging.ERROR) 

#after tests 
logger.setLevel(previous_level) 
+0

Sí, me esperaba un perezoso solución. Esa es la manera correcta de hacerlo, pero por ahora solo voy a hacer la misma configuración en la configuración. OBSERVACIÓN. – slinkp

+0

Sí, el problema es que la cláusula de excepción emite la advertencia pase lo que pase, por lo que desafortunadamente la única forma de detenerlo es bajar el nivel de registro. – jterrace

+6

No seas perezoso. Soy el pobre bastardo que tendrá que limpiar ese código después de que haya pasado a su próximo trabajo. –

1

sé algunos años pasaron pero para otros que buscan esta pregunta lo siguiente podría ser útil.

basado en la solución @jterrace fácilmente se podría implementar una función decorador de la siguiente manera:

import logging 

def prevent_request_warnings(original_function): 
    """ 
    If we need to test for 404s or 405s this decorator can prevent the 
    request class from throwing warnings. 
    """ 
    def new_function(*args, **kwargs): 
     # raise logging level to ERROR 
     logger = logging.getLogger('django.request') 
     previous_logging_level = logger.getEffectiveLevel() 
     logger.setLevel(logging.ERROR) 

     # trigger original function that would throw warning 
     original_function(*args, **kwargs) 

     # lower logging level back to previous 
     logger.setLevel(previous_logging_level) 

    return new_function 

Usando esto podría escribir el código como el siguiente:

@prevent_request_warnings 
def test_foo(self): 
    response = self.client.get('/foo/bar/') 
    self.assertEqual(response.status_code, 200) 
    response = self.client.get('/foo/bar2/') 
    self.assertEqual(response.status_code, 404) 
Cuestiones relacionadas