php - driven - cucumber

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

Question

¿Qué tan extendido, soportado, desarrollado está probando 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 PHP para ellos. Estoy preocupado por la calidad y el mantenimiento, ya que podría necesitar ayuda para esto.

Answer 1

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

Se trata esencialmente de un "desarrollo impulsado por la historia" para Ruby y, posiblemente, un estándar de oro en el ámbito de las pruebas funcionales, al menos en lo que respecta a mis viajes. (Puse esto en público, para que los expertos me corrijan si estoy equivocado)

Como ejemplo del lenguaje en Cucumber, tienes algo que se asemeja mucho a SQL. PERO parece ser aún más legible por humanos. Desde la página de inicio de cukes, su lenguaje 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 ejecutará como una prueba.

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

Al hacer eco de los comentarios anteriores, PHPUnit permitirá la prueba unitaria y de acuerdo con esta publicación del blog: http://sebastian-bergmann.de/archives/738-Support-for-BDD-and-Stories-in-PHPUnit-3.3.html también admite 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 objetos del navegador incorporada para la automatización del navegador, mientras que PHPUnit tiene una extensión para la automatización del navegador SELENIUM 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 encuentre esta información útil ya que es el resultado de varios meses de investigación personal y prueba y error práctico con las tecnologías mencionadas. Si hay expertos que pueden aclarar y mejorar mi comprensión de lo anterior, agradezco los comentarios.

• Alex.

Answer 2

Además de las bibliotecas / frameworks que Alan ya mencionó, puedes 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 utiliza salida TAP (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 en Perl y PHP. En mis propios proyectos, se necesita un poco de engaño y mucha lectura para que realmente funcione, pero una implementación de PHP está incorporada al 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 de Apache::Test y la guía mod_perl para ejecutar Apache :: Test . Además, encontré el artículo here gran ayuda.

Como un ejemplo rápido, puede configurar una prueba en Perl en muy pocas líneas de código que se ejecutará a través de todas las páginas de su sitio (que tienen enlaces) y verificar todos los resultados en respuestas '' 200 OK '' y no tiene ningún análisis errores:

#!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

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

Answer 4

Comparación de Michael Booth de las características de prueba de BDD en ambos idiomas:

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

concluye que las herramientas y la cultura PHP BDD están subdesarrolladas en este punto.

Ciertamente, no hay nada comparable con lo que está disponible para un programador de 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

Cuando hago un proyecto de TDD 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 conducido por comportamiento o " Especificación por ejemplo " me facilita la tarea de TDD , es decir, centrarme en el diseño, exponer mi intención y describir el comportamiento en contextos específicos . No estoy probando

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 impulsada por 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 característica (historias o pruebas de aceptación del usuario) considere Behat .

Volviendo a pecs, aquí hay un ejemplo seleccionado del sitio del proyecto pecs:

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í, eso 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.

Estos días 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 6

En un proyecto anterior, he usado PHPUnit, y me ha dejado con ganas. PHPUnit + Ejecución de la línea de comandos de las pruebas, lo hizo para que se gastara demasiado tiempo codificando las pruebas, no fue lo suficientemente rápido, y realmente parecía restringir el estilo del código de una manera que no me gustaba (los objetos eran más fácil 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 pruebas 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 sea más fácil lidiar con las pruebas en código.

Answer 7

Es posible que desee verificar PHPStorm . Me gustan los corredores de prueba que usan PHPUnit desde el IDE.

Answer 8

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

En cuanto a MVC Frameworks, Symfony tiene su propio marco de prueba llamado lime , Code Igniter tiene una biblioteca unit_test y CakePHP basa en el SimpleTest antes mencionado.

Sé que Zend Studio ha incorporado soporte para las pruebas de PHPUnit, y tanto PHPUnit como 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 de 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 desarrollador que su grupo va a contratar.

1. Pregúnteles qué marco de pruebas unitarias usan

2. Pídales que describan, en términos generales, un ejemplo del mundo real de una época en que desarrollaron una nueva función y sus pruebas de soporte.

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

Está menos interesado en la situación específica que describirá y más interesado en cuán cómodos están discutiendo su conocimiento de las pruebas de código en general.

Answer 9

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

Estoy de acuerdo con otros php ya que una plataforma de pruebas unitarias no es una experiencia divertida o BDD es la mejor manera de hacerlo si estás usando cualquier framework php

Envolver mi cabeza con el 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. Solíamos ejecutar nuestro conjunto de regresión en contra de nuestra aplicación CakePHP en un servidor de Jenkins, pero resultó ser no tan "lo suficientemente rápido"

Ahora nuestro flujo de trabajo es el siguiente: Crear una historia en pepinillo refinar la función de escritura de historias y completar cualquier paso nuevo. Comenzar a codificar la solución de php para probar. Luego, al final tenemos una función de trabajo o corrección de errores con una prueba bdd que lo cubre

Configuramos una máquina virtual Ubuntu con una configuración Behat en funcionamiento y la copiamos en todas las estaciones 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 muy fácil.

La clase Mink WebAssert le proporciona 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 descubrí que la curva de overhead / aprendizaje de configuración es demasiado alta en comparación con Behat.