Share
En los últimos dos artículos, hemos analizado de cerca la teoría detrás de las pruebas unitarias y cómo puede ayudarnos en nuestros esfuerzos de desarrollo de WordPress. Hemos definido las pruebas de unidad y hemos examinado varias maneras en que puede ayudarnos en nuestros proyectos..
Pero aún tenemos más por cubrir..
En este artículo final, revisaremos por qué deberíamos siquiera molestarnos en hacer pruebas unitarias y resumiremos las ventajas y desventajas de hacerlo. A continuación, veremos cómo podemos adaptar las pruebas en nuestros proyectos existentes. Y para resumir, resumiremos una lista de recursos que están disponibles específicamente para nosotros los desarrolladores de WordPress que ayudarán a comenzar a probar nuestros temas por unidad..
El tema general de esta serie entera ha sido sobre por qué deberíamos preocuparnos con las pruebas de unidad, pero si no se ha dicho de manera sucinta, esta es la razón:
Unit Testing nos ayuda a descubrir problemas en una etapa temprana, proporciona a los desarrolladores un nivel de código de auto-documentación y nos brinda un nivel más alto de calidad de software.
Por supuesto, esto supone que seguimos practicando buenas técnicas de prueba de unidad. Por supuesto, esto fue cubierto con gran detalle en el artículo anterior, pero vale la pena reiterarlo..
Una cosa importante a tener en cuenta, especialmente si está tratando de aplicar esto en un entorno más corporativo o en el contexto de una empresa más grande, es que las pruebas unitarias no son solo algo que los desarrolladores hacen por sí mismos. La calidad tiene dos caras: beneficia al cliente y beneficia al negocio.
Al proporcionar un mayor nivel de calidad para el cliente, es decir, un software más probado, deberían experimentar menos errores. Dado que los errores resultan en el tiempo que los desarrolladores deben dedicar a resolver en lugar de trabajar en nuevos proyectos o nuevas características de productos existentes, esto puede ahorrar dinero.
Al proporcionar un mayor nivel de calidad para el negocio, los desarrolladores tienen más confianza en sus esfuerzos porque pueden ejecutar una serie de pruebas cada vez que se realiza un cambio al saber cómo afectó su trabajo a toda la aplicación. Si una prueba falla, entonces pueden resolverla antes de implementarla en producción.
Unit Testing tiene que ver con la calidad y afecta no solo a quienes escriben el código, sino también a la empresa que lo envía y a los clientes que lo están utilizando..
La verdad es que ya hemos cubierto las ventajas de las pruebas unitarias. Para completar, resumámoslos aquí (¡aunque siempre puedes revisarlos en detalle!). Examen de la unidad…
Todo suena bien, ¿verdad? Y sí, se basa en que los desarrolladores se responsabilicen de los altos estándares y prácticas a la hora de implementar esto en el trabajo diario, pero las pruebas unitarias no están exentas de desventajas..
Esto se ha dicho a lo largo de esta serie: las pruebas unitarias requieren una importante inversión de tiempo. Es cierto que si está comenzando un nuevo proyecto, la inversión de tiempo es mucho menor que si está ajustando esto en una aplicación existente, pero está todavía Tener que escribir más código que sin probar.
Debido a que está escribiendo más código, está demorando más tiempo, nuevamente, en la parte delantera del proyecto. Los beneficios de las pruebas unitarias a menudo no llegan hasta más tarde, pero si un proyecto tiene una fecha específica de lanzamiento y esa versión incluye una cierta cantidad de funciones, es probable que no se adapten a todas las pruebas unitarias y las características la liberación.
Si desea evitar conjuntos de características más pequeños en fechas de lanzamiento o demoras, tener para construir a tiempo para la prueba de la unidad.
Los has escuchado a todos: la complejidad mata, mantenlo simple, estúpido, menos es más, etc..
Honestamente, todos estos son verdaderos y tienen su lugar adecuado en el desarrollo, pero el hecho es que las pruebas de unidad es código adicional y código adicional siempre Introduce más complejidad. Como tal, tenemos que asegurarnos de que tenemos una manera adecuada de administrar y organizar todas nuestras pruebas de unidad.
Quizás sea la organización de archivos, el espacio entre nombres, las convenciones de nomenclatura, las pruebas versionadas o todo lo anterior. Independientemente de lo que termine haciendo, las pruebas unitarias no deben tratarse como ciudadanos de segunda clase en el mundo del software; deben estar sujetos a los mismos principios de diseño que otras clases o funciones tanto como sea posible.
Sí, en el último artículo dijimos que las pruebas unitarias pueden ayudar a impulsar el diseño de una aplicación y pueden ayudar a fomentar un diseño que haga que toda la aplicación sea más comprobable. Esto sigue siendo cierto, pero tiene un costo: a veces el diseño más comprobable por unidad no es el más claro.
Con eso quiero decir que debido a que un conjunto de funciones, o incluso una clase, está totalmente probado por unidades, la cohesión tiene el potencial de verse comprometida porque estamos haciendo sacrificios para acceder a ciertas funciones para verificar su procesamiento de datos. Por supuesto, esto no es una regla difícil y rápida y puede que incluso no sea un problema para algunos, pero tiene que decidir de qué va a ser dogmático: es un conjunto de clases y funciones perfectamente diseñado o Un sistema contiguo de pruebas y funciones que trabajan en conjunto.?
En última instancia, creo que todo se reduce a cómo se ven las pruebas como una parte más amplia del conjunto. Si forman parte del diseño de la aplicación, es posible que el diseño no sufra. Pero si ve las pruebas como una idea de último momento, entonces el diseño de la aplicación principal puede verse comprometido solo ligeramente.
Como dicen, el software nunca se hace y, como las pruebas unitarias forman parte de un software, nunca se hacen..
Debido a que una aplicación siempre va a evolucionar, ya se trate de errores que se eliminen, se introduzcan nuevas funciones (o incluso se eliminen), las pruebas asociadas también deberán agregarse o actualizarse. Y siempre vuelve al tiempo..
Además, si está trabajando en un equipo de desarrolladores, nuestra falta de pruebas de actualización puede afectar negativamente al equipo, ya que los resultados que reportan las pruebas pueden ser falsos positivos o falsos negativos. Una vez que se escriben las pruebas, es imperativo que se actualicen; De lo contrario, pueden resultar en un producto muy pobre..
Unit Testing es mucho más fácil de vender cuando está comenzando con un proyecto, pero si está buscando adaptarlo a una aplicación existente (o tema o complemento, en nuestro caso), tomará un poco de tiempo y esfuerzo.
Y aunque no hay una bala de plata sobre cómo puede ejecutarse perfectamente en esto, hay algunas buenas maneras de comenzar a implementar la práctica en su trabajo diario:
Si sigue los pasos anteriores, eventualmente terminará con una cantidad significativa de cobertura de código. Sí, lleva tiempo y sí es probable que tenga que volver a trabajar una gran parte del código, pero esa misma inversión de tiempo dará dividendos en el futuro de su producto..
Aquí hay un resumen de los recursos que pueden contribuir a las pruebas exitosas de sus proyectos basados en WordPress:
Entre la primera serie de artículos y esta serie de artículos, se ha sentado una base sólida sobre la cual puede continuar construyendo sus prácticas de prueba de unidad..
Accentsconagua