Por qué se realizan pruebas
Las pruebas pueden ser una herramienta eficaz para mejorar la calidad, la arquitectura y el estado general de una base de código. En esta unidad, se analizarán algunas de las formas en que las pruebas pueden tener un impacto positivo en el sector del software.
Validación de los cambios y la calidad del código
Cualquier software con éxito tiende a crecer en funcionalidad y comportamiento. A veces puede crecer más allá de lo que los creadores nunca imaginaron para admitir más escenarios y solicitudes de clientes. A medida que crece la funcionalidad, puede resultarle difícil a un solo desarrollador recordar todas las funciones que contiene o realizar el seguimiento de cómo conservar esa funcionalidad.
Las pruebas no solo realizan el seguimiento de las distintas funcionalidades de un programa, sino que también pueden seguir comprobando que la funcionalidad anterior no se ha interrumpido a medida que se ha agregado código nuevo. Un propósito fundamental de las pruebas es el de validar que los cambios de código no interrumpirán la funcionalidad existente y garantizar que el código recién agregado seguirá funcionando según lo previsto, incluso con cambios futuros.
Las pruebas pueden ayudar a detectar errores antes incluso de confirmar los cambios de código. Un procedimiento recomendado consiste en ejecutar pruebas antes de los pasos principales del ciclo de desarrollo. Esta comprobación final le permite mejorar la calidad del código para que los usuarios no tengan que notificar que algo se ha interrumpido en la actualización más reciente. Es mucho más fácil detectar errores mientras continúa el desarrollo del código que durante la implementación de la aplicación o cuando ya está en producción y los cliente la usan. La detección de errores al principio del ciclo de desarrollo ahorra tiempo y dinero.
Ejemplos del sector
Puede encontrar un buen ejemplo de la potencia de las pruebas en el propio compilador de C#. Millones de desarrolladores escriben código en C# a diario. ¿Alguna vez se ha preguntado cómo las herramientas pueden seguir agregando características del lenguaje y publicando nuevas versiones del lenguaje sin que se interrumpa el código existente? Las pruebas proporcionan un conjunto final de cientos de miles de comprobaciones para asegurarse de que los escenarios anteriores siguen funcionando. Es imposible que una persona o incluso un equipo recuerde todos esos escenarios.
Es especialmente cierto cuando se tiene en cuenta que el compilador de C# es de código abierto y acepta contribuciones de una comunidad mundial de desarrolladores. El equipo del compilador de C# puede aceptar cambios de la comunidad con confianza, en parte debido a las comprobaciones que proporcionan las pruebas. Las pruebas son útiles para los usuarios y en el nivel de equipo, lo que le permite escalar el producto y el equipo a medida que crecen.
Efectos sobre la arquitectura
Las pruebas también pueden forzar algunas mejoras de la arquitectura. No puede probar partes pequeñas del código si está estructurado como un único método enorme. Las pruebas pueden ayudarle a dividir todas las funciones del código en componentes más modulares. Las pruebas pueden reducir la repetición, mejorar la estabilidad e incluso facilitar la lectura y la navegación del código.
Por ejemplo, si usa la misma lógica en muchos lugares de la aplicación y, después, se da cuenta de que hay un problema con ella, tendrá que buscar y actualizar todos los lugares en los que la ha usado. Pero si usa un método, solo tiene que actualizarlo una vez, ya que aunque se llame a ese método muchas veces en la aplicación, solo ha escrito la lógica una vez en el cuerpo del método.
Las pruebas le ayudan a detenerse y pensar si repite la misma lógica varias veces y en su lugar podría usar un método. Proporciona a los desarrolladores la oportunidad de reestructurar el código para obtener la mejor capacidad de reusabilidad y estabilidad para el futuro.
Cobertura de código y estado del código
La cobertura de código es una métrica que indica la cantidad de código de producción de una aplicación que abarcan las pruebas. Indica si las pruebas realmente ejecutan todo el código de producto, incluidas la lógica de bifurcación y las sobrecargas de métodos. La cobertura de código puede proporcionar una idea básica de qué áreas necesitan más pruebas. Visual Studio tiene herramientas que incluso pueden resaltar qué líneas abarcan las pruebas y cuáles no en el editor.
El seguimiento del porcentaje de cobertura de código en el tiempo puede indicar si el código nuevo que se agrega al repositorio tiene pruebas. Si el código nuevo no se prueba, podría ser una señal de que en el repositorio se genera deuda técnica. Aunque la cobertura de código es útil, no es indicación definitiva del estado del repositorio. Solo debe ser uno de los muchos factores que se usan para evaluar el estado de un repositorio.
Los distintos motores de cobertura de código pueden calcular la cobertura de forma diferente y muchos programas pueden parecer tener una cobertura baja, a pesar de que se prueben correctamente. Por ejemplo, realizar muchas pruebas en métodos concretos que se utilizan mucho e ignorar otros podría ser realmente lo correcto para un repositorio determinado. No es recomendable que todos los repositorios intenten lograr una cobertura de código del 100 %, ya que para muchas empresas no es una inversión práctica.
Hay mucho debate sobre si existe o no un porcentaje de cobertura de código universal al que los repositorios deben aspirar. Por ahora, consideramos que la mejor guía es juzgar cada caso de forma individual y no someter arbitrariamente al equipo a una cifra fija sin una explicación más profunda.