Probar los bits importantes en PHP

Escribir software de calidad es una actividad técnicamente desafiante y costosa. La parte técnicamente desafiante proviene de la necesidad de comprender e implementar más de un tipo de prueba de aplicaciones. Considerando que, la parte costosa proviene del hecho de que las pruebas adecuadas generalmente produce más código que el código que estamos probando, lo que se traduce en más tiempo necesario para hacer el trabajo.

A diferencia de los desarrolladores, a las empresas no les importan tanto los tecnicismos, sino la reducción de costos. Aquí es donde los dos mundos chocan a expensas de la calidad. Si bien ambos entienden las implicaciones de un concepto de deuda técnica, rara vez pocos lo toman en serio.
Las aplicaciones web vienen a la mente como un buen ejemplo de este choque. El diseño y la experiencia de usuario lo suficientemente buenos son a menudo suficientes para satisfacer las necesidades de los accionistas, mientras que muchas de las partes internas y las partes del software que quedan fuera del alcance de los ojos quedan sin probar.

Echa un vistazo a https://en.wikipedia.org/wiki/Technical_debt para más Información sobre el concepto técnico de la deuda.

Existen muchos tipos de pruebas que podemos aplicar a nuestra aplicación, algunas de las cuales son las siguientes:

  • Examen de la unidad
  • Pruebas Funcionales
  • Pruebas de rendimiento
  • Pruebas de usabilidad
  • Test de aceptación

Sería injusto decir que uno es más importante que el otro, ya que cada uno aborda un segmento muy distinto de la aplicación. El estado actual del ecosistema y las herramientas de PHP indica que las pruebas unitarias, funcionales y de rendimiento se encuentran entre las más populares. En este tutorial, echaremos un vistazo rápido a algunas de las herramientas y bibliotecas que se adaptan a estos tipos de pruebas:

  • PHPUnit
  • Behat
  • phpspec
  • jMeter

El software que un programador típico cree que se ha probado exhaustivamente a menudo solo ha ejecutado entre el 55 y el 60 por ciento de sus rutas lógicas. El uso de soporte automatizado, como los analizadores de cobertura, puede aumentarlo aproximadamente del 85 al 90 por ciento. Es casi imposible probar el software al nivel del 100 por ciento de sus rutas lógicas.

– Hechos y falacias de la ingeniería del libro de software.

Comparte