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

https://stackoverflow.com/questions/530712

22-08-2019
|

Pregunta

¿Qué tan extendidas, soportadas y desarrolladas están las pruebas en el mundo PHP?¿A la par con Java?¿A la altura de Ruby/Rails?Busqué en Google y descubrí que existen marcos de prueba, pero me pregunto si se utilizan ampliamente.

¿Los principales IDE de PHP tienen ejecutores de pruebas integrados como lo hacen las herramientas Java de Eclipse o las herramientas Ruby/Rails de NetBeans?¿Las pruebas están integradas en los marcos MVC de PHP como con Rails?

Lo pregunto porque un grupo donde trabajo quiere contratar a alguien para que les desarrolle una aplicación PHP.Me preocupa la calidad y el mantenimiento, ya que es posible que me llamen para respaldar esto.

Solución

Hay al menos dos conjuntos de pruebas maduras, independientes y de estilo JUnit disponibles, denominadas Unidad PHP y Prueba simple, respectivamente.

En lo que respecta a los marcos MVC, Symfony tiene su propio marco de prueba llamado cal, Code Igniter tiene un prueba de unidad biblioteca y pastelPHP se basa en el SimpleTest antes mencionado.

Sé que Zend Studio ha incorporado soporte para pruebas PHPUnit, y tanto PHPUnit como SimpleTest tienen ejecutores 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 sí las aprovechan.

Las advertencias son parte del curso de quejas de PHP.Hay dos comunidades PHP;PHP como plataforma para crear software y PHP como forma de interactuar con un servidor web, un navegador web y una base de datos para producir elementos similares a aplicaciones en la web.Es menos una cosa de blanco y negro y más una continuidad;Entre los que están más en el lado del desarrollador de software, las pruebas unitarias y TDD son compatibles y utilizados tanto como en cualquier otra plataforma.Entre las personas que "improvisan un montón de cosas que no entiendo pero aún así obtengo resultados", es algo inaudito.

Hay una gran cantidad de código PHP heredado que no es de marco o de marco personalizado y que es difícil conseguir un método 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 que respalde esto aparte de mis propias observaciones, pero muchas tiendas de 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, prueba primero, etc.desarrollo.

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

Pregúnteles qué marco de pruebas unitarias utilizan.
Pídales que describan, en términos generales, un ejemplo del mundo real de una ocasión en la que desarrollaron una nueva característica y sus pruebas de respaldo.
Pídales que describan, en términos generales, un ejemplo del mundo real en el que sus pruebas fallaron y qué hicieron para resolver la situación.

Está menos interesado en la situación específica que van a describir y más en qué tan cómodos se sienten al discutir su conocimiento de las pruebas de código en general.

Otros consejos

Cada vez que un proyecto TDD con herramientas de estilo xUnit, tengo problemas para conseguir mi cabeza en el lugar correcto. Me parece que el uso de herramientas diseñadas para Comportamiento Driven Development o " Especificación por ejemplo " hace que sea más fácil para mí < a href = "http://gojko.net/2010/12/02/the-principle-of-symmetric-change/" rel = "noreferrer"> hacer TDD derecho - es decir, enfoque en el diseño, exponiendo intención y describir el comportamiento en contextos específicos . No prueba.

Una vez dicho esto, me gustaría introducir pectorales en la conversación. Desde el readme en el sitio del proyecto.

pectorales es una pequeña biblioteca de desarrollo guiado por comportamiento para PHP 5.3, a la RSpec o JSpec.

Si ha utilizado JSpec o mejor aún, Jasmine-BDD (JavaScript) el estilo pectorales de describir el comportamiento debe ser muy familiar. Me parece que este estilo grande para las especificaciones de nivel de componente. Si está buscando una herramienta PHP para especificaciones de nivel de función (historias o pruebas de aceptación de usuario) 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 de pectorales, parece que el autor es capaz de sacar esto adelante mediante el aprovechamiento de la nueva picor en PHP 5.3+, Lambdas y cierres. Así que supongo que esto significa que no se puede utilizar pectorales en cualquier proyecto basado en PHP <5.3 (lo digo).

Además, pectorales no es tan madura como PHPUnit o SimpleTest. Sin embargo, creo que los defensores de la BDD en la comunidad de PHP deben apoyar el crecimiento de las herramientas como pectorales que animan a "Especificación con el ejemplo" o BDD sin la confusión provocada por tener que utilizar herramientas de prueba XUnit heredados.

Estos días trabajo más que en Python PHP. Sin embargo, la próxima vez que cojo un proyecto PHP, voy a ser muy feliz si tengo una herramienta madura, con el apoyo de la comunidad como pectorales para elaborar las especificaciones para el software.

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

Embalaje mi cabeza alrededor de compositor como una herramienta de construcción de recompra era el mayor obstáculo, pero hemos sido capaces de utilizar Behat Mink selenio WebDriver tarro de servidor independiente como una herramienta de diseño y pruebas de regresión increíble. Se utilizó para ejecutar nuestra suite de regresión en contra de nuestra aplicación CakePHP en un servidor Jenkins, pero resultó ser no tan "a prueba rápida" suficientemente

Ahora nuestro flujo de trabajo es el siguiente: Crear historia en pepinillo refinar historia escriba función y apagar cualquier nuevo paso defs comenzará 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 configuración de una máquina virtual de Ubuntu con un trabajo Behat instalación y copiado en cada estación de trabajo. Nos lo cocían en nuestro proceso. Nos debe hacer es desplegar los cambios se ejecutan las pruebas de codificación entonces comienzan cosas nuevas.

Se escribió un script de shell para ejecutar automáticamente MySQL vertederos y cargarlos antes de cada función que ha hecho código de refactorización una brisa.

La clase de visón WebAssert le da todas las afirmaciones que necesita para validar el comportamiento Las clases regulares sesión / CommonContext son grandes para el uso de CSS o XPath.

He utilizado Carpincho / WebDriver con Java y los carriles de proyectos antes y encontrado la sobrecarga de configuración / curva de aprendizaje es demasiado alta en comparación con Behat.

Además de las bibliotecas / marcos que Alan ya ha mencionado, se puede hacer uso de mod_perl de Apache :: prueba, que lo que yo uso como un arnés. Me permite integrar de manera muy sencilla pruebas en mi proceso de liberación. El arnés utiliza TAP salida (Protocolo Cualquier cosa Test) para determinar si o no las pruebas pasan o fallan , el uso de las bibliotecas como Test :: simple o prueba :: Más ( Perl y < a href = "http://shiflett.org/code/test-more.php" rel = "nofollow noreferrer"> PHP).

Fuera del núcleo de Apache :: Prueba admite pruebas de escritura, tanto en Perl y PHP. En mis propios proyectos, se tardó un poco de engaños y una gran cantidad de leyendo para realmente conseguir que funcione, pero una implementación de Test :: Más en PHP es incorporado al arnés. Correr todas las pruebas escritas en PHP y Perl se realiza a través de un mando único y cualquier fallo en el camino se captura Apache :: prueba, teniendo en cuenta la mejor manera posible lo que salió mal.

La parte increíble de todo esto es que incluso se puede utilizar PHPUnit, o simple test junto a los dos marcos de pruebas anteriores. Mediante la ejecución de pruebas en cada biblioteca respectiva, puede utilizar la aplicación PHP de Test :: More (o incluso Perl por la salida estándar de prueba) y escupir de vuelta TAP para su arnés de interpretar.

Asegúrese de leer la Apache :: documentación de prueba y la guía mod_perl de ejecutar Apache :: prueba . Además, he encontrado el artículo aquí una gran ayuda.

Como un ejemplo rápido, usted 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 todo el resultado en las respuestas de los 200 OK 'y no tienen 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.");
}

En un proyecto anterior, he utilizado el PHPUnit, y me ha dejado con ganas. línea de PHPUnit + Comando ejecución de las pruebas, hecha de tal manera que se pasaba demasiado tiempo codificación de las pruebas, no era lo suficientemente rápido, y realmente parecía limitar el estilo del código de una manera que no me gusta (objetos eran más fáciles de probar, por lo que parecía un poco favorecer a objetos).

El selenio era una solución que hemos hablado, pero nunca llegó a entrar en juego, y creo que realmente se han beneficiado de este tipo de pruebas a nivel de salida.

En este último proyecto, el jefe de programación ha adoptado un enfoque de programación más funcional, ya que hemos estado revisando el software. Cuando le dije que me gustaría código a través de TDD, se prepararon rápidamente una solución personalizada en un día o menos que considero que ha sido tan eficaz para mí utilizar como PHPUnit. Además, él realmente me abrió los ojos sobre la cuestión de la orientada a objetos frente a la programación funcional.

En primer proyecto, iniciado a partir de cero, en la planta baja, orientada a objetos de codificación, amplio marco de pruebas unitarias, se hizo monolítica y empantanado rápidamente. Segundo proyecto, el software CMS bien establecida con una historia de 5 años y código antiguo, sin embargo, un paradigma de programación funcional y un marco de pruebas simples (que de hecho a menudo hizo uso de php afirman) hizo llegar más simple en lugar de crecer en complejidad.

El segundo proyecto, también, nunca llegó hasta el punto de aplicación de selenio (y sigo pensando que sería beneficioso), pero el enfoque de la programación funcional hizo más fácil para hacer frente a las pruebas en código.

Me acabo esta pregunta y, mientras estoy todavía en la "etapa de investigación" en averiguar lo que está pasando. Acabo de descubrir algo para Ruby on Rails llamados "Pepino" http://cukes.info/

Se trata esencialmente de 'desarrollo de la historia impulsada' por Ruby y muy posiblemente un estándar de oro en el campo de las pruebas funcionales, al menos por lo que yo he visto en mis viajes. (Pongo esto no públicamente, por lo que los expertos me puede corregir si me equivoco)

A modo de ejemplo de la lengua en Pepino, tienes algo que se parece mucho a SQL. y parece ser aún más legible. Desde la primera página cukes su idioma es el siguiente:

 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 que es todo preámbulo del punto de responder a su pregunta sobre PHP -. TDC y TDD

Al hacerse eco de los comentarios anteriores, PHPUnit permitirá a la unidad de pruebas y de acuerdo con esta entrada del blog: http://sebastian-bergmann.de/archives/738-Support-for-BDD-and-Stories-in-PHPUnit-3.3.html también apoya "estilo historia" pruebas de BDD.

Para ampliar la respuesta anteriormente con respecto a "SimpleTest" mencionado anteriormente, el sistema ST ha construido en una clase de objeto del navegador para la automatización del navegador, mientras que PHPUnit tiene una extensión para la automatización del navegador SELENIO http://seleniumhq.com (la ventaja de selenio frente a SimpleTest es que Selinium se ejecutará cualquier javascript en páginas mientras SimpleTest voluntad no).

Espero que esta información sea útil, ya que es el resultado de varios meses de investigación y práctica personal de ensayo y error con las tecnologías anteriores. Si hay expertos por ahí que puede aclarar y mejorar mi comprensión de lo anterior, celebro la retroalimentación.

Alex.

Comparación de Michael Booth funciones de prueba de TDC en ambos idiomas:

http://mechanicalrobotfish.com / mensajes / 117-ruby-vs-php-bdd-belleza-concurso-no-concurso

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

Desde luego no hay nada comparable con lo que está disponible a un programador Ruby, ya sea en términos de conocimiento (libros, videos, artículos, blogs) o herramientas (RSpec, Shoulda, Factory Girl, Mocha, pepino).

Es posible que desee echa un vistazo a PhpStorm . Me gustan los corredores de las pruebas que utilizan PHPUnit desde el IDE.

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

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow