¿Cómo cito un trabajo con PHPUnit?

He estado haciendo programación de sitios web durante 15 años y PHP durante los últimos 5 años más o menos. Siempre he escrito código sólido. SIN EMBARGO, tengo un cliente que insiste en que se pruebe la unidad en el 80% del código. Como el cliente SIEMPRE ES CORRECTO, estoy planeando usar PHP_CodeSniffer para asegurarme de que mi código se vea bien y PHPUnit para hacer la prueba de mi unidad. Espero aprender algo a través de esta experiencia.

¿Son estas las herramientas adecuadas para usar? ¿Cuánto tiempo implica configurar PHPUnit y escribir el código adicional? Me tomará alrededor de 8 semanas escribir las páginas web y la autocomprobación como lo he hecho en el pasado. Si agrego 4 días adicionales (10%) para pruebas unitarias (PHPUnit), ¿es suficiente? Pensamientos? Sugerencias? Gracias.

En una línea: depende de cómo trabajes. Creo sinceramente que el 10% es demasiado poco. Debe ser al menos 25%, si no 40%, si no 60%, si no más.

Primero, estoy muy de acuerdo con su cliente allí. Las pruebas unitarias son una parte esencial de un producto robusto, fácil de mantener y fácil de depurar.

Hablaré de lo que sé. Yo uso TDD (Test-Driven Development) para la mayoría de los proyectos. TDD básicamente te hace escribir las pruebas antes del código real. Establecen un conjunto de criterios de aceptación que el producto final debe cumplir. Por lo general, pasará del 50% al 70% de su tiempo escribiendo pruebas y el resto para implementar el código para que pasen.

Si bien puede sonar absurdo y / o enorme, puedo asegurarle que no lo es. Este es el por qué:

• Podrá descubrir cuáles son los mejores patrones arquitectónicos para usar mientras escribe las pruebas. De esta manera, cuando comience a codificar, la arquitectura de la aplicación cambiará mínimamente (porque todos sabemos lo costoso que es rehacer una arquitectura de aplicación).
• Usted codifica solo para hacer pasar las pruebas (por lo tanto, hacer que el producto final sea aceptable). No perderá tiempo programando funciones inútiles / fuera de alcance.
• Al tener menos código (es decir, solo el código que realmente necesita), es menos propenso a errores. (Menos código = menos errores).
• Si comete un error, y lo hará, tomará mucho menos tiempo descubrir por qué hay un problema y dónde está el problema. Si las pruebas se escriben correctamente, significa que un solo error causará una sola falla, no una reacción en cadena. De esta manera, puede identificar fácilmente la fuente del problema en cuestión de minutos, si no segundos.
• Llevará mucho menos tiempo implementar el código real con las pruebas unitarias. Tan pronto como una prueba falla, sabes que algo está mal. No tiene que ir y venir con el cliente para corregir errores.
• Eventualmente tendrá que hacer un intercambio de información con el cliente para corregir errores, porque nada puede detectar el 100% de los errores. Sin embargo, puede atrapar fácilmente el 95%, si no más.

PHPUnit es más o menos la herramienta de facto para pruebas unitarias de PHP, y es muy bueno en eso. No he usado mucho PHP_CodeSniffer. Sin embargo, creo que si está trabajando solo, probablemente no lo necesite. Es más útil en un equipo asegurarse de que el código se vea igual sin importar quién lo haya codificado.

Te apoya para tener la actitud de que aprenderás algo de esta experiencia. Estoy seguro de que lo haras.

Lo primero que debe aprender es que la necesidad de las pruebas unitarias no tiene nada que ver con la experiencia que tenga . El mejor desarrollador también será uno de los mejores probadores de unidades:

Bill Venners: Dices en tu libro Refactorización: "Si quieres refactorizar, la condición previa esencial es tener pruebas sólidas". ¿Eso significa que si no tienes pruebas no deberías refactorizar?

Martin Fowler: Debes pensar que es caminar sobre una cuerda floja sin una red. Si eres bueno para caminar sobre la cuerda floja, y no es tan alto, entonces puedes intentarlo. Pero si nunca antes ha caminado sobre la cuerda floja, y está sobre las Cataratas del Niágara, probablemente quiera una buena red.

^{De http://www.artima.com/intv/refactorP.html}

Solía ​​escribir PHP sin pruebas unitarias. Luego, después de años de practicar pruebas unitarias en Java, descubrí que no podía trabajar en nada mucho más complicado que páginas individuales en PHP sin pruebas unitarias. ¿La razón? Productividad . Sin las pruebas unitarias, no podría refactorizar con confianza; esto significaba que, ya sea A) tendría que derribar mucho más y trabajar en todo desde el principio nuevamente, o B) , tendría que lidiar con el código feo y heredado.

Cuando realiza una oferta, ¿necesita tener en cuenta el tiempo para realizar la prueba? Sí . ¿Parece intuitivo que eso llevará más tiempo? Si otra vez . Probablemente, como algunas otras respuestas han estimado aproximadamente, necesitará estimar 50-100% mayor que sin pruebas unitarias.

¡Sin embargo!...

• Capturará y abordará agujeros de especificación antes
• Lo que significa que estará desarrollando una especificación más limpia y sólida
• Podrá responder rápida y confiadamente a los cambios de especificaciones
• Tendrás menos errores
• Sus errores serán detectados antes y más fácil de arreglar

Y como resultado, sus estimaciones serán más precisas . Si cobra por hora, impresionará más a sus clientes y podrá aumentar sus tarifas. Si cobra una tarifa plana, ganará más dinero por hora.

Sin pruebas, lo más probable es que sus estimaciones sean un desastre. Los errores, las órdenes de cambio y las redefiniciones son terribles para estimar con precisión. ¡La prueba es la clave para minimizar el impacto de los tres!

No hay una respuesta fácil sobre cuánto tiempo más le llevará.

Pero como regla general, si es un proyecto corto: diría que el desarrollo junto con buenas pruebas unitarias tomará 1.75-2 veces más que el desarrollo sin pruebas unitarias. ¿Para proyectos más largos tal vez 25-30%?

Sugiero hacer pruebas unitarias antes de escribir su código. Tomado de esta manera, la construcción del andamio de prueba de la unidad realmente se convierte en una parte de su proceso de diseño, por lo que no debe considerar que está perdiendo tiempo en la prueba de la unidad, sino que la construcción de la prueba de la unidad lo está ayudando a diseñar un Un gran producto y la existencia de esa prueba después de que la hayas creado te facilita asegurarte de que siga siendo así. Tener que escribir primero las pruebas unitarias es maravilloso para ayudarnos a enfocarnos en los requisitos reales, nos brinda una forma clara de evaluar si hemos terminado (aprobar las pruebas unitarias) y nos ayuda a "evaluar temprano y evaluar a menudo".

En cuanto a PHPUnit ... Ha pasado un tiempo desde que lo usé, mi impresión es que es poderoso, pero tal vez necesite más trabajo antes de que esté realmente pulido.

Sin embargo, si hay una cosa que quiero comunicar aquí: por favor, no vea Unit Testing como una mera formalidad al final de su proyecto. Si eso es todo, en mi opinión, no tiene valor.

Las respuestas hasta ahora son bastante exhaustivas, así que solo agregaré un punto no cubierto: el tiempo adicional debido al uso de PHPUnit será

1. más alto al principio ya que lo estás aprendiendo, y
2. reduzca el tiempo de desarrollo sin prueba a medida que gane confianza con él.

Las clases de modelos de pruebas unitarias que no se ocupan de la presentación son bastante sencillas. Escribe una prueba para cada clase y, en esos casos de prueba, puede crear instancias directamente y configurar un objeto para probar un método / característica en particular. Una vez que haya configurado y ejecutado PHPUnit, podrá hacer que estas pruebas funcionen rápidamente.

Las páginas web de prueba de unidad pueden ser más complicadas. Si usa Zend Framework, Symfony, Smarty o cualquier otro motor MVC, hacer que PHPUnit funcione bien con ellos puede llevar más tiempo. Usamos Zend Framework y pasé una cantidad considerable de tiempo creando clases base para probar controladores y ver scripts de forma aislada. Dado el tamaño de este proyecto, probablemente sea mejor comenzar ControllerTestCase.