Quiero presentar el concepto de pruebas unitarias (y pruebas en general) a mis compañeros de trabajo; en este momento no hay pruebas en absoluto y las cosas se prueban realizando las tareas a través de la interfaz de usuario para ver el resultado deseado. Como puede imaginar, el código está estrechamente vinculado a la implementación exacta, incluso dando como resultado que el código que debería estar en una clase y reutilizarse en todo el sistema se copie y pegue en todos los métodos.
Debido a los requisitos modificados, me han pedido que modifique un módulo que escribí anteriormente y que está bastante acoplado (no tanto como me gustaría, pero lo mejor que puedo obtener sin tener que introducir muchos otros conceptos). He decidido incluir un conjunto de pruebas unitarias con mi código revisado para "probar" que funciona como se esperaba y demostrar cómo funciona la prueba; No sigo TDD verdadero ya que parte del código ya está escrito, pero espero seguir algunos conceptos de TDD para el nuevo código que tendré que crear.
Ahora, inevitablemente, estoy seguro de que me preguntarán por qué me lleva más de un día o dos escribir el código, ya que partes de lo que interactuaré ya existen en el sistema (aunque sin ninguna prueba y muy estrictamente acoplado), y cuando verifico el código, me preguntarán qué es este proyecto de "Pruebas". Puedo explicar los conceptos básicos de las pruebas, pero no puedo explicar los beneficios reales de una manera que los demás entenderían (porque piensan que las pruebas requieren que ejecute la aplicación usted mismo, ya que a menudo la interfaz de usuario real es importante para determinar si la función "funciona" " o no). No entienden la idea del acoplamiento flojo (claramente evidente por el hecho de que nada está acoplado libremente; ni siquiera hay interfaces fuera del código que he escrito), así que tratar de usar eso como un beneficio probablemente me haría ganar un "¿Eh?" tipo de aspecto, y una vez más, no puedo estar tan suelto como me gustaría sin tener que volver a trabajar varios módulos existentes y probablemente introducir algún tipo de contenedor IoC, que se consideraría como una pérdida de tiempo y no "programación".
¿Alguien tiene alguna sugerencia sobre cómo puedo señalar este código y decir "Deberíamos comenzar a crear pruebas unitarias" sin parecer ya sea condescendiente (por ejemplo, "Escribir pruebas lo obliga a escribir un buen código", lo que probablemente se interpretaría como código excepto que el mío es malo ) o sin que parezca una pérdida de tiempo que no agrega ningún valor real?
fuente