¿La prueba de la unidad es del 100% o no en todo tipo de trato?
Estaba explorando mis proyectos anteriores y comencé a agregar funciones, esta vez con la prueba de unidades. Sin embargo, ¿esto no tiene ningún valor en última instancia si voy a reutilizar componentes anteriores que no tienen pruebas unitarias?
¿Necesito escribir pruebas de unidad para todas las clases anteriores y no me molesta en absoluto, o está bien solo escribir pruebas de unidad para las nuevas cosas que estoy agregando?
Cualquier prueba de unidad es mejor que ninguna. Así que no es un trato de todo o nada.
En su caso, dado que Test Driven Development no ha sido la norma, se preguntará cómo las pruebas son de alguna utilidad.
Desea asegurarse de que cualquier código futuro que escriba no rompa ninguna funcionalidad (actual) , y ahí es donde sus subcasos son útiles. Si las pruebas bien escritas pasan, lo más probable es que no haya dañado nada. El siguiente desarrollador que venga te agradecerá las pruebas y la documentación.
Con lo que puede comenzar es si tiene una arquitectura en capas bien dividida, recoja los niveles de acceso a datos y trabaje hacia arriba (hacia el nivel UI) con las pruebas. Si el proyecto tiene un modelo de dominio, es el candidato más probable para TDD, ya que es probable que tenga la mayor parte de la lógica. Si el nivel de servicio (o lógica empresarial) solo está haciendo una llamada al nivel de acceso a dominio / datos, no tiene ningún sentido hacer el nivel de servicio en modo TDD. Esas son pruebas esponjosas y no tienen mucho valor.
Se agregó a una herramienta de cobertura de código como Emma, y puede monitorear constantemente la mejora en la cobertura general de las pruebas.
He trabajado en una base de código muy grande que inicialmente no tenía pruebas unitarias. Al seguir algunas prácticas, ahora (después de varios años) tenemos la mayor parte del código base cubierto por las pruebas.
Todo código nuevo debe tener pruebas unitarias.
Todos los códigos modificados deben tener pruebas unitarias agregadas.
La forma en que agregamos de forma segura las pruebas al código antiguo sin romperlo consiste principalmente en utilizar el siguiente enfoque básico:
Elija una pequeña sección de código de la que necesite cambiar la funcionalidad.
Introduzca las interfaces que necesita para poder probar el código que está cambiando. Utilice las técnicas de refactorización que consisten en secuencias de cambios muy pequeños que usted tiene alta confianza son correctas. Trate de usar soporte de herramientas cuando sea posible. Puede hacer esto, por ejemplo, moviendo / extrayendo el método que está cambiando en su propio objeto. Verifica tus cambios regularmente para que puedas revertirlos. Revise periódicamente la forma en que realizó los cambios al revisar el historial de control de revisión.
Intente hacer el mínimo de cambios necesarios para romper las dependencias que le impiden agregar pruebas.
Descubrimos que cuanto más hacíamos esto, más fácil era. Como cada vez que vuelves a la base del código, es un poco mejor.
Hemos visto una caída masiva en el número de errores que llegan a nuestros evaluadores de control de calidad. Ya que las regresiones de funcionalidad son casi desconocidas, creo que valió la pena el esfuerzo para nosotros.
(por la falta de capacidad de comentar) Creo que es mejor que no probar en absoluto. No es necesario probar todos los fragmentos de código, sino solo lo que el programador utilizará eventualmente. Probar las funciones de utilidad que usa internamente es bueno, pero no es necesario si accede a todo a través de una API limpia posteriormente.
Si las cosas antiguas han estado funcionando bien durante años, crear las pruebas unitarias ahora no es obligatorio a menos que cambies algo en las cosas antiguas. De todos modos, escribir pruebas unitarias para las nuevas partes no es para nada inútil. Las nuevas partes son las que tienen más probabilidades de contener errores, y también son las que tienen más probabilidades de ser cambiadas o refactorizadas.
Puede comenzar a cubrir su código actual y, si tiene algo de tiempo, comenzar a cubrir la funcionalidad principal del código anterior. También puedes pedirle a tu PM algún tiempo extra para eso =)
¿La prueba de la unidad es del 100% o no en todo tipo de trato?
¡Absolutamente no! Comience a probar el nuevo código que está agregando. Verá inmensos beneficios al hacer eso, incluso si algunos de los componentes más antiguos no tienen pruebas. Cuando tenga que lidiar con uno de esos componentes, o encuentre un error en él, escriba una prueba. Con el tiempo, obtendrás más del código anterior bajo prueba.
Lea otras preguntas en las etiquetas unit-testing