En mi trabajo uso constantemente pruebas unitarias. Que hay de ti En mi experiencia, la mayoría de los programadores son muy raros. Cuando entrevisto a candidatos de trabajo en mi equipo, siempre hago la pregunta: "¿Tienes alguna experiencia en las pruebas?" Y la mayoría de las veces escucho en respuesta: "No." Y si pregunta por qué, entonces la respuesta más común será: "El cliente no me dejó hacer esto".

Este enfoque me sorprende. ¿Le dirá al constructor qué marca de concreto elegir para construir una casa? O mecánica automotriz: ¿qué parte del motor reparar y cuál no, si el motor ha parpadeado en el automóvil? Es poco probable, porque estos son problemas técnicos graves, cuya solución debe confiarse a un profesional. Un profesional tiene las habilidades y herramientas necesarias que le permiten resolver un problema más rápido y más barato.

¿Por qué contar el dinero?

El Código Civil tiene el concepto de "salvar a un contratista a través de la experiencia y el conocimiento". Su significado es que el trabajo lo realiza un profesional que sabe cómo optimizar el proceso, cómo hacerlo mejor, pero al mismo tiempo más barato. Y los desarrolladores como profesionales deberían ofrecer al cliente las mejores soluciones por el menor dinero.

Pero en realidad, los programadores se centran en otra cosa. Muchos de ellos están seguros de que el desarrollo de software es un proceso puramente técnico, que, por supuesto, tiene su valor, pero el trabajo del programador es escribir, no contar dinero. Sin embargo, en mi opinión, el desarrollo es principalmente un proyecto económico, detrás del cual hay dinero y cálculos, y solo después de eso es una tarea técnica.

La lógica aquí es simple: los negocios, para los mismos clientes que nos ordenan el desarrollo de software para sus empresas, de hecho, no necesitan ningún software. Las empresas necesitan dinero, los beneficios que traerá este software.

Esto significa que los programadores no pueden prescindir de comprender la economía del desarrollo, conocer el costo de las soluciones técnicas y cuáles son óptimas no solo en términos de tecnología, sino también de finanzas.

El desarrollo de software generalmente no es la parte más barata del negocio, pero el software de baja calidad puede generar grandes pérdidas. Incluso el tiempo de inactividad conduce a la pérdida de beneficios, y los problemas de software pueden conducir a millones de pérdidas. Por lo tanto, el desarrollador como profesional debe confiar en la calidad de su producto y garantizarlo a su cliente. Pero la calidad del producto es el indicador más importante. Y el cliente debe saber que esta calidad se puede medir y confiar en ella. Y cómo es exactamente la tarea del programador.

Yo, como muchos de mis colegas, creo que los programadores no deberían discutir soluciones de ingeniería con el cliente. En general, es suficiente saber qué es importante para el cliente, qué funcionalidad y para qué fines necesita. Qué decisiones elegir es responsabilidad del programador. Y en el marco de esta responsabilidad, debe utilizar las mejores prácticas de ingeniería para un proyecto determinado con costos económicamente justificados. Por lo tanto, los profesionales que saben cómo hacer que el proceso de desarrollo sea más barato ganan.

¿Qué prueba es más rentable?

Una práctica que le permite controlar la calidad del producto es la prueba. Pero, ¿qué prueba es más rentable? Para responder a esta pregunta, es suficiente comparar varios parámetros. Todas las pruebas se pueden dividir condicionalmente no solo por tipo de tecnología, sino también por velocidad y, lo más importante, por costo.

Prueba de unidad : prueba de unidades de producción. Por unidades me refiero a las unidades de programa, dependiendo del lenguaje representado por las clases, las funciones y los archivos con menos frecuencia. Utilizando el enfoque TDD, las pruebas se entrelazan inicialmente en el proceso de desarrollo del producto. Un proyecto puede usar miles de tales pruebas para probar piezas individuales de código. Tienen un excelente indicador de velocidad: todo el conjunto de pruebas se puede completar en segundos. Estas son las pruebas más baratas.

Pruebas de integración : prueba de 2x-3x o más unidades juntas. Puede haber cientos o miles de tales pruebas en un proyecto, dependiendo del programador. Velocidad: segundos o minutos para todo el conjunto de pruebas. El costo es más alto que las pruebas unitarias.

Las pruebas de aceptación simulan acciones del usuario con un programa. Requieren la preparación de un entorno operativo; por lo tanto, son complejos y costosos. Cantidad por proyecto: por lo general, se realiza una prueba para una historia de negocios. La velocidad de trabajo suele ser de decenas de minutos a varias horas para todo el conjunto de pruebas.

La más costosa y difícil es la prueba manual . Debe contratar a una persona, capacitarla, crearla y entregarle un mapa de historial comercial para que pruebe el nuevo software en él. Dichas pruebas demoran varios días para todo el conjunto de pruebas.

Cualquier tipo de prueba requiere preparación, así como una cierta inversión de dinero. Y para obtener ahorros (y, por lo tanto, beneficios), primero debemos tener en cuenta la velocidad de las pruebas y la complejidad de su lanzamiento. Si el proyecto no tiene pruebas automáticas, entonces solo hay una salida: las pruebas manuales, las más costosas y lentas.

Sin embargo, el enfoque moderno para el desarrollo de software es un ciclo continuo: en una semana se crea una nueva funcionalidad o una nueva versión y se comprueba de forma automática o manual. Es decir, el producto cambia con frecuencia, y todos estos cambios deben controlarse para que el programador esté seguro de que las nuevas y viejas funcionalidades funcionan bien. Por lo tanto, las pruebas manuales pierden inmediatamente en todos los indicadores.

En cuanto a los diferentes tipos de pruebas automáticas, hay tres aspectos más importantes a considerar.

En primer lugar, es la fiabilidad : lo fácil que es romper la prueba (este es el mejor indicador para las pruebas unitarias).

Luego, el entorno que se necesita para ejecutar las pruebas. Las pruebas unitarias son muy simples, ellas mismas crean un entorno alrededor de la unidad bajo prueba. Las pruebas de integración requieren un servicio que se debe instalar, ejecutar, etc. Las pruebas de aceptación requieren preparación, ya que la aplicación debe funcionar en su entorno.

Y finalmente - cobertura (cobertura de prueba). Las pruebas unitarias tienen buena cobertura y se utilizan durante todo el proyecto. Las pruebas de integración generalmente se usan en ciertas partes del proyecto, es decir, no cubren completamente el programa. La cobertura de las pruebas de aceptación es peor: esto se debe a la complejidad de escribirlas y ejecutarlas, la mayoría de las veces cubren los principales casos de negocios, esto es 20-40% del volumen total del proyecto.

Conclusión

Por lo tanto, resulta que las pruebas unitarias son líderes en todos los indicadores de este breve análisis comparativo. En mi práctica, la mayoría de las veces los uso, me da suficiente calidad. Si aumentan los requisitos de calidad, pasamos a la aceptación. El uso de pruebas de integración depende del cliente, que puede querer probar ciertas partes del proyecto.

Mi actual pila de tecnología es angular y .net. Y si en el lado del servidor las pruebas no generan grandes preguntas, entonces probar la aplicación del cliente sigue siendo, en muchos lugares, no obvio para todos. En los proyectos de mis clientes, el número de pruebas unitarias varía de unos pocos cientos a varios miles. En el próximo artículo intentaré compartir técnicas clave para probar aplicaciones angulares.