¿Cuál es el estado de TDD y/o BDD en PHP?

Question

¿Qué tan extendido, compatible y desarrollado está el testing en el mundo de PHP? A la par con Java? Arriba con Ruby/Rails? Busqué en Google y descubrí que existen marcos de prueba, pero me pregunto si son ampliamente utilizados.

¿Los principales IDE de PHP tienen corredores de prueba incorporados del mismo modo que las herramientas de Eclipse en Java o las herramientas de Ruby/Rails de NetBeans? ¿Las pruebas están integradas en los frameworks MVC de PHP como con Rails?

Pregunto porque un grupo donde trabajo quiere contratar a alguien para desarrollar una aplicación de PHP para ellos. Estoy preocupado por la calidad y el mantenimiento, ya que podría necesitar ayuda para esto.

Answer 1

Existen al menos dos suites de prueba de estilo JUnit maduras e independientes disponibles, llamadas PHPUnit y SimpleTest, respectivamente.

En cuanto a los marcos MVC ir, Symfony tiene su propio marco de pruebas llamado lime, CodeIgniter tiene una biblioteca unit_test y CakePHP se basa en la SimpleTest antes mencionado.

Sé que Zend Studio ha incorporado soporte para las pruebas de PHPUnit, y PHPUnit y SimpleTest tienen corredores de línea de comandos, por lo que es posible la integración en cualquier flujo de trabajo.

Las herramientas están ahí en el mundo PHP si un desarrollador quiere aprovecharlas, y las tiendas inteligentes se aprovechan de ellas.

Las advertencias son su parte para las quejas PHP del curso. Hay dos comunidades de PHP; PHP como una plataforma para desarrollar software, y PHP como una forma de interactuar con un servidor web, navegador web y base de datos para producir cosas similares a aplicaciones en la web. Es menos una cosa en blanco y negro y más un continuo; Entre los que están más en las pruebas de unidades laterales del desarrollador de software, TDD es compatible y se usa tanto como en cualquier otra plataforma. Entre los "adoquines hay un montón de cosas que no entiendo pero que aún me dan resultados", es algo inaudito.

Hay una gran cantidad de códigos PHP heredados que no son de framework o frameworks personalizados, por lo que es difícil obtener un arnés de prueba útil. PHP también se presta fácilmente a patrones que dependen de la existencia de un entorno de navegador para ejecutarse. No tengo ninguna evidencia para respaldar esto aparte de mis propias observaciones, pero muchas tiendas PHP que se preocupan por las pruebas terminan confiando en las pruebas de aceptación (es decir, Selenio) como sustituto de las Pruebas unitarias reales, las pruebas primero, etc. desarrollo.

En su situación específica, entreviste al reverendo al desarrollador que su grupo va a contratar.

1. preguntarles qué marco de pruebas de unidad que utilizan

2. Pídales que describan, en términos generales, un ejemplo del mundo real de una época que desarrolló una nueva característica y sus pruebas que apoyan

3. Pídales que describan, en términos generales, un ejemplo real del tiempo en que fallaron sus pruebas y lo que hicieron para resolver la situación

Le interesan menos las situaciones específicas que van a describir y le interesa más saber cuán cómodos están discutiendo sus conocimientos sobre las pruebas de códigos en general.

Answer 2

Además de las bibliotecas/marcos que Alan ya ha mencionado, puede hacer uso de Apache :: Test de mod_perl, que es lo que uso como arnés. Me permite integrar pruebas muy simplemente en mi proceso de lanzamiento. El arnés usa TAP de salida (Test Anything Protocol) para determinar si las pruebas pasan o no, utilizando bibliotecas como Test::Simple o Test :: More (Perl y PHP).

Fuera de la caja Apache :: Test admite pruebas de escritura tanto en Perl como en PHP. En mis propios proyectos, tomó un poco de bit of trickery y mucha lectura para realmente ponerlo en funcionamiento, pero una implementación de Test::More in PHP está incorporada en el arnés. Ejecutar todas las pruebas escritas tanto en PHP como en Perl se realiza a través de un solo comando y cualquier falla en el camino se captura Apache :: Test, anotando lo mejor que puede, lo que salió mal.

Lo mejor de todo esto es que incluso puede utilizar PHPUnit o Simple-Test junto con los dos marcos de prueba anteriores. Al ejecutar las pruebas en cada biblioteca respectiva, puede usar la implementación de PHP de Test :: More (o incluso Perl probando stdout) y escupir TAP para que su arnés lo interprete.

Asegúrese de leer la documentación Apache::Test y mod_perl guide to running Apache::Test. Además, encontré el artículo here de gran ayuda.

Como un ejemplo rápido, puede configurar una prueba en Perl en muy pocas líneas de código que se ejecutará en todas las páginas de su sitio (que tienen enlaces) y verificará todos los resultados en '200 OK' y no tener cualquier error de análisis:

#!perl 

use strict; 
use warnings; 

use Apache::Test qw(:withtestmore); 
use Apache::TestRequest; 
use Test::More; 
use Test::WWW::Mechanize; 
use WWW::CheckSite::Validator; 
use WWW::CheckSite::Spider; 

plan 'no_plan'; 

my $config = Apache::Test::config(); 
my $host = "http://". Apache::TestRequest::hostport($config) || ''; 

my $s = WWW::CheckSite::Spider->new(
    uri => $host, 
    ua_class => 'Test::WWW::Mechanize', 
); 
my $m = $s->current_agent; 

while (my $page = $s->get_page) { 
    is($m->status(), "200", $m->uri() ." retrieved successfully."); 
    $m->content_lacks("Parse Error", $m->uri() ." does not contain syntax errors."); 
} 

Answer 3

En un proyecto pasado, he utilizado el PHPUnit, y me ha dejado con ganas. PHPUnit + La ejecución de la línea de comando de las pruebas, hizo que pasase demasiado tiempo codificando las pruebas, no fue lo suficientemente rápido, y realmente pareció restringir el estilo del código de una manera que no me gustó (Los objetos eran más fáciles de probar, por lo que parecía favorecer un poco los objetos).

Selenium fue una solución de la que hablamos pero que nunca llegó a entrar en juego, y creo que realmente nos hubiéramos beneficiado de ese tipo de pruebas a nivel de salida.

En este último proyecto, el programador principal ha adoptado un enfoque de programación más funcional ya que hemos estado revisando el software. Cuando mencioné que me gustaría codificar a través de TDD, creó una solución personalizada en un día o menos que considero que fue tan efectiva para usar como PHPUnit. Además, realmente me abrió los ojos sobre la cuestión de la Programación Orientada a Objetos vs. Funcional.

Primer proyecto, empezado desde cero, en la planta baja, codificación Orientada a Objetos, un gran Marco de Prueba de Unidades, se volvió monolítico y se empantanó rápidamente. El segundo proyecto, un software CMS bien establecido con una historia de 5 años y un código antiguo, pero un paradigma de programación funcional y un marco de prueba simple (en realidad usamos el php assert) lo hizo más simple en lugar de crecer en complejidad.

El segundo proyecto, nunca llegó al punto de implementar Selenium (y todavía creo que sería beneficioso), pero el enfoque de programación funcional hizo que fuera más fácil lidiar con las pruebas en código.comparación de

Answer 4

Michael Booth funciones de prueba de TDC en ambos idiomas:

http://mechanicalrobotfish.com/posts/117-ruby-vs-php-bdd-beauty-contest-no-contest

llega a la conclusión de que las herramientas y la cultura PHP TDC está poco desarrollado en este punto.

Ciertamente no hay nada comparable con lo que está disponible para un programador Ruby, ya sea en términos de conocimiento (libros, videos, artículos, publicaciones en blogs) o herramientas (Rspec, Shoulda, Factory Girl, Mocha, Cucumber).

Answer 5

Acabo de encontrar esta pregunta y, mientras todavía estoy en la "etapa de investigación" en averiguar qué está pasando. Acabo de descubrir algo para Ruby on Rails llamado "Pepino" http://cukes.info/

Esencialmente, el desarrollo impulsado por la historia de Ruby y posiblemente un estándar de oro en el ámbito de las pruebas funcionales, al menos hasta donde he visto en Mis viajes. (Puse esto en público, para que los expertos me corrijan si estoy equivocado)

Como ejemplo del lenguaje en Cucumber, tiene algo que se asemeja mucho a SQL. PERO parece ser aún más legible por humanos. Desde la primera página cukes su lengua se ve así:

Scenario: Add two numbers 
     Given I have entered 50 in the calculator 
     And I have entered 70 in the calculator 
     When I press add 
     Then the result should be 120 on the screen 

Lo anterior se compilará y se ejecuta como una prueba.

Ahora todo es un preámbulo al punto de responder a su pregunta sobre PHP - BDD & TDD.

Al hacer eco de los comentarios anteriores, PHPUnit permitirá las pruebas unitarias y de acuerdo con esta publicación de blog: http://sebastian-bergmann.de/archives/738-Support-for-BDD-and-Stories-in-PHPUnit-3.3.html también es compatible con la prueba BDD de "estilo de historia".

Para ampliar la respuesta anterior con respecto a "SIMPLETEST" mencionado anteriormente, el sistema ST tiene una clase de objeto incorporada para la automatización del navegador, mientras que PHPUnit tiene una extensión para SELENIUM browser automation http://seleniumhq.com (la ventaja de Selenium vs SimpleTest es que Selinium ejecutará cualquier javascript en la página, mientras que SimpleTest no lo hará).

Espero que esta información le resulte útil, ya que es el resultado de varios meses de investigación personal y prueba práctica y error con las tecnologías anteriores. Si hay expertos que pueden aclarar y mejorar mi comprensión de lo anterior, agradezco los comentarios.

• Alex.

Answer 6

Siempre que realicé un proyecto con herramientas de estilo XUnit, tengo dificultades para encontrar mi cabeza en el lugar correcto. Encuentro que el uso de herramientas diseñadas para el desarrollo impulsado por comportamiento o "Specification by example" me facilita do TDD right, es decir, me concentro en el diseño, en la exposición de intenciones y describing behaviour in specific contexts. No pruebas.

Dicho esto, me gustaría introducir pecs en la conversación. Del archivo léame en el sitio del proyecto.

pecs es una pequeña biblioteca de desarrollo basada en el comportamiento para PHP 5.3, a la RSpec o JSpec.

Si usó JSpec o mejor aún, Jasmine-BDD (para JavaScript), el estilo pecs de describir el comportamiento debería ser muy familiar. Este estilo me parece genial para las especificaciones de nivel de componentes. Si está buscando una herramienta PHP para las especificaciones de nivel de función (historias o pruebas de aceptación del usuario), considere Behat.

Volviendo a los pectorales, he aquí un ejemplo entresacado del sitio del proyecto pectorales:

describe("Bowling", function() { 
    it("should score 0 for a gutter game", function() { 
    $bowling = new Bowling(); 
    for ($i=0; $i < 20; $i++) { 
     $bowling->hit(0); 
    } 
    expect($bowling->score)->to_equal(0); 
    }); 
}); 

Sí que es una especificación de PHP. Mirando a través de la fuente pecs, parece que el autor puede sacar provecho al aprovechar el nuevo hotness en PHP 5.3+, Lambdas y cierres. Así que supongo que esto significa que no puede usar pecs en ningún proyecto basado en PHP < 5.3 (solo FYI).

Además, pecs no es tan maduro como PHPUnit o SimpleTest. Sin embargo, creo que los defensores de BDD en la comunidad de PHP deberían apoyar el crecimiento de herramientas como pecs que fomentan "Especificación por ejemplo" o BDD sin la confusión provocada por el uso de herramientas de prueba de XUnit heredadas.

Actualmente trabajo más en Python que en PHP. Sin embargo, la próxima vez que elija un proyecto de PHP, estaré muy contento si tengo una herramienta madura y compatible con la comunidad como pecs para diseñar las especificaciones del software.

Answer 7

Ahora estoy desarrollando marco "Spectrum" para la prueba de BDD: https://github.com/m-haritonov/spectrum

Answer 8

Es posible que desee echa un vistazo a PHPStorm. Me gustan los corredores de prueba que usan PHPUnit desde el IDE.

Answer 9

he tenido una experiencia increíble con Behat/Mink http://behat.org

Estoy de acuerdo con los demás PHP como una plataforma de pruebas de unidad no es una diversión o experiencia BDD es el mejor camino a seguir si usted está usando alguna herramienta PHP

Envolver mi cabeza alrededor del compositor como una herramienta de compilación de repo fue el mayor obstáculo pero pudimos utilizar el servidor independiente Behat Mink Selenium Webdriver como una increíble herramienta de prueba de regresión y diseño. Se utilizó para ejecutar nuestra suite de regresión en contra de nuestra aplicación CakePHP en un servidor Jenkins pero resultó no ser tan "a prueba rápida" suficientemente

Ahora nuestro flujo de trabajo es el siguiente: Crear historia en pepinillo artículo de fondo escritura refinar y apagar cualquier nuevo defs paso comienzan solución de codificación de PHP para probar Luego, al final hemos una característica o corrección de errores trabajo con una prueba bdd cubriéndolo

nos configurar una máquina virtual de Ubuntu con un trabajo Behat instalación y copiado a cada estación de trabajo. Lo horneamos en nuestro proceso. Simplemente desplegamos cambios, ejecutamos pruebas y luego comenzamos a codificar cosas nuevas.

Escribimos un script de shell para ejecutar automáticamente volcados de mysql y cargarlos antes de cada característica que ha hecho que el código de refactorización sea sencillo.

La clase Mink WebAssert le da todas las afirmaciones que necesita para validar el comportamiento Las clases de sesión regular/CommonContext son excelentes para usar css o xpath.

He usado Capybara/WebDriver con proyectos de Java y Rails antes y encontré que la curva de sobrecarga/aprendizaje de configuración es demasiado alta en comparación con Behat.