¿Cómo hago para configurar un proceso de desarrollo de TDD con Google App Engine?

Question

Soy principalmente un chico de Ruby, pero últimamente he estado trabajando en muchas cosas de Python, en particular, el código de App Engine. En Ruby, utilizaría integración automática continua (autotest), herramientas de cobertura de código (rcov), análisis estático (reek) y pruebas de mutación (heckle) en mi proceso de desarrollo, pero no estoy seguro de cómo configurar una proceso de desarrollo similar para un entorno de App Engine. También me interesarían los análogos a RSpec y Cucumber para Python que podrían funcionar en App Engine.

Answer 1

En mi proyecto GAE, que utilizo:

• NoseGAE — Esta es la pieza fundamental que une a todos el resto juntos
• Simulacro, como en la excelente respuesta de John. Yo uso esta en gran medida de AWS y otros servicios web
• Accesorios (el paquete, no es la idea)

También prefiero muchos de los modismos de Rieles. Rompí mis pruebas en unidades y funcional usando paquetes de Python. Puede ejecutar un subconjunto de pruebas usando --tests=unit o --tests=functional. Es todo un poco más manual que Rails, pero al menos puedo probar las cosas difíciles y asegurarme de que nunca tenga regresiones.

También hice una clase simple FunctionalTest para hacer muchas de las acciones más comunes en Rails, como assert_response y assert_xpath (similar a assert_select).

class FunctionalTest(Test): 
    def get(self, *args, **kw): 
    self.response = app.get(*args, **kw) 

    def post(self, *args, **kw): 
    self.response = app.post(*args, **kw) 

    def assert_response(self, expected): 
    pattern = str(expected) if re.search(r'^\d+$', expected) \ 
          else (r'^\d+ %s' % expected) 
    assert re.search(pattern, self.response.status, re.IGNORECASE), \ 
      'Response status was not "%s": %s' % (expected, self.response.status) 

    def assert_xpath(self, path, expected): 
    element = ElementTree.fromstring(self.response.body) 
    found_nodes = element.findall('.' + path) 
    if type(expected) is int: 
     assert_equal(expected, len(found_nodes)) 
    elif type(expected) is str or type(expected) is unicode: 
     assert (True in [(node.text == expected) for node in found_nodes]) 
    else: 
     raise Exception, "Unknown expected value: %r" % type(expected) 

Si usted está haciendo un montón de búsquedas de igualdad ListElement, sin duda aprender la sintaxis --tests=foo porque las pruebas para los elementos de juego dentro de una lista es muy lento.

A veces me gusta cargar la consola de Rails con los datos de mi dispositivo para ver qué ocurre en el entorno de prueba (es decir, script/console test). Para hacer algo similar con GAE, ejecute dev_appserver.py con el parámetro --datastore_path="$TMPDIR/nosegae.datastore" (o posiblemente sustituir /tmp para $TMPDIR.

Answer 2

No siempre encontrará equivalentes uno a uno de las herramientas de prueba de Ruby en Python, pero hay algunas excelentes herramientas de prueba en Python. Algunas de las herramientas que he encontrado útiles incluyen:

• unittest - la herramienta xUnit incluido en la biblioteca estándar de Python. Incluye todos los elementos básicos para la prueba unitaria.
• doctest - una parte impresionante de la biblioteca estándar, le permite escribir pruebas en los documentos de funciones, clases, módulos, métodos. Es excelente para transmitir el uso previsto de API. Ian Bicking sugiere usar doctest para el desarrollo conducido por comportamiento. Doctest se adapta muy bien al sistema de documentación Sphinx (puede asegurarse de que todos los ejemplos en su documentación pasen cada vez que compila los documentos).
• nose y py.test se ven como las versiones de próxima generación de unittest. Pueden ejecutar todos los casos de prueba unitaria existentes, pero permiten pruebas de unidades más sencillas, que no se basan en la clase. py.test también permite la ejecución distribuida.
• mock es una buena biblioteca para el comportamiento burlón.
• tdaemon mira un directorio para las actualizaciones de su código y volverá a ejecutar su suite de pruebas. (mi personal branch contiene algunas mejoras no mejoradas).
• Buildbot, Bitten, e incluso Hudson funcionan bien como servidores completos de integración continua para código Python.
• coverage.py calcula la cobertura del código de su código.
• pylint proporcionará un análisis similar a una pelusa de su código, asegurándose de que sigue las convenciones de codificación comunes y no tiene ningún error común. También hay una herramienta de análisis "más ligera", PyFlakes.
• Hay varias herramientas de prueba HTTP/Browser que funcionan bien en Python, incluyendo Twill, Selenium y Windmill.

Si está utilizando Django en App Engine, que incluye several extensions a unittest que permiten simular un cliente HTTP y la persistencia de base de datos.

Hay un montón de otras herramientas que no he usado (como PySpec y Behaviour) que también podrían ser útiles. No he visto ninguna herramienta de prueba de mutaciones en Python, pero apuesto a que hay una por ahí (me gustaría saber qué es).

¡Pruebas felices!

Answer 3

no ha utilizado App Engine, pero mi sentimiento por las herramientas de prueba pitón más populares es

• unittest/doctest son los paquetes de prueba de la norma biblioteca de Python. unittest es la xUnit para python.
• nose es un corredor/buscador de prueba. Tiene muchas opciones, incluyendo --with-coverage, que usa coverage para darle cobertura de código informes.
• pylint es el inspector de pelusas más útil para python. Es útil más allá de un corrector de sintaxis, ya que informa sobre variables/funciones no utilizadas, cuando los métodos deben ser funciones, y más.
• pester (pruebas de mutación)
• buildbot (integración continua)

Usted probablemente querrá hacer referencia a esta lista (no del todo completa) de Python Testing Tools.

Para BDD, el campo estaba delgado la última vez que lo comprobé. Muchas de las verdaderas herramientas BDD no se podían usar con la nariz y/o limitaban demasiado la sintaxis que requerían. Puede tener un poco de suerte con spec, que es un complemento de tipo nariz BDD. Acabo de encontrar pyccuracy, que se parece mucho al pepino, pero no lo he probado en .

Por lo que su valor, ahora sólo tiene que utilizar nosetests -v (el corredor nariz con --verbose), que utilizará la primera línea de la cadena de documentación en el corredor de prueba salida. Es decir, dada una prueba como:

class TestFoo(unittest.TestCase): 
    def testAnyNameHere(self): 
     """ Foo should be bar""" 
     foo = "bar" 
     self.assertEqual(foo, 'bar') 

nosetests dará:

$ nosetests -v 
Foo should be bar... ok 

----------------------------- 
Ran 1 tests in 0.002s 
OK 

Answer 4

Parece que otra nueva opción es Agar, que se basa en google.appengine.ext.testbed, parte del SDK de App Engine. Ver this blog post para más detalles