it-swarm-es.com

¿Cómo hacer Test Driven Development (TDD) en Drupal?

  • ¿Cuáles son las herramientas que usa TDD en Drupal (módulos PHP, Drupal módulos, etc.)?
  • ¿Cómo es su flujo de trabajo de confirmación/prueba/implementación? ¿Utiliza Phing, PHPUnderControl, Hudson para administrar este flujo de trabajo?
  • ¿De qué manera las pruebas unitarias hacen su código más confiable?
  • ¿Necesita un servidor de prueba de unidad independiente, costoso e independiente, o puede hacerlo desde una computadora portátil?

Sé que Robert escribió una excelente publicación técnica aquí sobre pruebas unitarias en Drupal con SimpleTest; estoy más interesado en cubrir el flujo de trabajo y la parte de configuración. Actualmente tengo un máquina de desarrollo, servidor de montaje y producción Los sitios de producción y escenario se ejecutan en una CPU Dreamhost VPS de 300 MB de RAM/300 MHz.

29
amateur barista

En el mundo Ruby), TDD se ve facilitado por las herramientas integradas en el marco. Factory Girl, Mocha, rSpec y otros permiten a los desarrolladores crear pruebas de forma fácil y dinámica que aborden los casos de prueba necesarios.

También me ha frustrado la falta de herramientas TDD en Drupal. Mi mayor problema con ellos es la cantidad de tiempo que lleva ejecutar una sola prueba. Los ciclos de desarrollo no se pueden ralentizar mediante pruebas individuales que tardan entre 60 y 90 segundos en cada iteración. Los conjuntos de pruebas completos se ejecutarían en el marco de tiempo de varias horas, si se molesta en escribir las pruebas.

Sospecho que tiene que ver con copiar una base de datos completa cada vez que se ejecuta una prueba, pero no es probable que eso cambie en el futuro cercano de lo que puedo decir, especialmente si necesita usar DrupalWebTestCase para hacerlo.

Estoy pirateando una solución usando Phactory y phpunit, que arranca Drupal manualmente. Obviamente me encuentro con algunos problemas y no lo he terminado, pero está llegando allí.

Afortunadamente, la mayor parte de mi trabajo está en la capa de fondo, por lo que puedo permanecer en el nivel DRUPAL_BOOTSTRAP_DATABASE. Pero me encuentro con más situaciones en las que necesitaré la pila completa.

Al final, TDD en Drupal no está bien soportado, por lo que puede escribir el suyo propio para que funcione fuera del marco de prueba drupal, o soportar el bajo rendimiento.

- ACTUALIZACIÓN -

He configurado con éxito una integración completa Drupal con Phactory, y ahora estoy ejecutando mis pruebas a través de phpunit en lugar de Drupal Web Test Case. Entonces es posible.

Espero llegar a un punto en el que pueda liberarlo y pueda incorporarse al documento de Phactory.

- ACTUALIZACIÓN 2 -

Doc sobre cómo configuro Phactory está en https://github.com/trimbletodd/phactory .

8
trimbletodd

Como el blog de Mark está fuera de línea, mencionaré algunas de las herramientas que su equipo ha implementado:

Pruebas funcionales: selenio
Prueba de unidad: más simple
Servidor de compilación: Jenkins
Evaluación comparativa del rendimiento: XDebug + Cachegrind

En los dos años desde que hice esta pregunta, he visto algunas herramientas adicionales ganar popularidad en la escena TDD. Hoy en día, cuando se habla de Desarrollo impulsado por pruebas (en un contexto Drupal contexto, por supuesto) hay dos caras de la misma moneda: pruebas de front-end y pruebas de back-end.

Aquí hay dos presentaciones que se destacan del último Drupalcon Portland 2013 que representan este asunto:

Desarrollo, por los números , pruebas de backend.
Pruebas automatizadas con Jasmine y PhantomJS , pruebas frontend.

La primera presentación no está relacionada con pruebas unitarias o funcionales (estrictamente hablando), se trata más de herramientas para medir la calidad del código. Sin embargo, siento que está algo relacionado con el tema.

13
amateur barista

Lo único que sé es que para los módulos contribuidos, puede habilitar la prueba automatizada de confirmaciones y parches en la cola de problemas, vea - http://drupal.org/node/68999 . Todavía es algo inestable, especialmente si tiene dependencias.

La mayoría de los proyectos probablemente están haciendo algo más en la línea del desarrollo impulsado por errores, que básicamente se reduce a escribir una prueba primero cuando se encuentra un error y luego corregirlo. Como mucho ;)

Desde mi experiencia personal, TDD es bastante difícil en Drupal, porque a menudo no escribes (solo) pruebas unitarias con las pruebas más simples sino de integración, donde ves páginas y envías formularios. Por lo tanto, puede ser bastante difícil escribir buenas pruebas por adelantado. Pero tal vez no estoy acostumbrado a hacerlo :)

5
Berdir