unit testing - ejemplo - ¿Por qué la calidad del código no es popular?
tdd (30)
¿Por qué la calidad del código es tan impopular?
Porque nuestra profesión es poco profesional.
Sin embargo, hay personas que se preocupan por la calidad del código. Puede encontrar personas afines, por ejemplo, en el grupo de discusión del movimiento Software Craftsmanship . Pero, desafortunadamente, la mayoría de las personas en el negocio de software no entienden el valor de la calidad del código, o ni siquiera saben lo que constituye un buen código.
Me gusta que mi código esté en orden, es decir, correctamente formateado, legible, diseñado, probado, revisado para detectar errores, etc. De hecho, soy un fanático de ello. ( Tal vez incluso más que fanático ... ) Pero en mi experiencia, las acciones que ayudan a la calidad del código apenas se implementan. (Por código de calidad, me refiero a la calidad del código que produce día a día. Todo el tema de la calidad del software con los procesos de desarrollo es mucho más amplio y no es el alcance de esta pregunta).
La calidad del código no parece popular. Algunos ejemplos de mi experiencia incluyen
Probablemente, todos los desarrolladores de Java saben JUnit, casi todos los lenguajes implementan los marcos xUnit, pero en todas las compañías que conozco, solo existían muy pocas pruebas unitarias adecuadas (si es que existían). Sé que no siempre es posible escribir pruebas de unidad debido a limitaciones técnicas o fechas límite de entrega, pero en los casos que vi, la prueba de unidad hubiera sido una opción. Si un desarrollador quería escribir algunas pruebas para su nuevo código, podría hacerlo. Mi conclusión es que los desarrolladores no quieren escribir pruebas.
El análisis de código estático a menudo se juega en pequeños proyectos, pero en realidad no se utiliza para hacer cumplir las convenciones de codificación o encontrar posibles errores en proyectos empresariales. Por lo general, se ignoran incluso las advertencias del compilador, como el posible acceso al puntero nulo.
Los conferencistas y las revistas hablarían mucho sobre EJB3.1, OSGI, Cloud y otras nuevas tecnologías, pero casi no sobre nuevas herramientas o tecnologías de prueba, nuevos enfoques de análisis de código estático (por ejemplo, resolución de SAT), procesos de desarrollo que ayuden a mantener una mejor calidad. algunas bestias desagradables de código legado fueron puestas a prueba, ... (No asistí a muchas conferencias y probablemente se vea diferente para conferencias sobre temas ágiles, como pruebas de unidad e IC, y eso tiene un mayor valor allí).
Entonces, ¿por qué la calidad del código es tan impopular / considerada aburrida?
EDITAR:
Gracias por sus respuestas. La mayoría de ellos se refieren a pruebas de unidad (y se ha discutido en una pregunta relacionada ). Pero hay muchas otras cosas que se pueden usar para mantener la calidad del código alta (consulte la pregunta relacionada ). Incluso si no puede usar las pruebas unitarias, puede usar una compilación diaria, agregar un análisis de código estático a su IDE o proceso de desarrollo, probar la programación en pares o imponer revisiones de código crítico.
Probablemente todos los desarrolladores de Java saben JUnit ...
Si bien creo que la mayoría o muchos de los desarrolladores han oído hablar de los marcos de prueba JUnit / nUnit / other, menos saben cómo escribir una prueba utilizando dicho marco. Y de ellos, muy pocos tienen una buena comprensión de cómo hacer que la prueba sea parte de la solución.
Conozco las pruebas de unidad y los marcos de prueba de unidad durante al menos 7 años. Intenté usarlo en un pequeño proyecto hace 5 a 6 años, pero solo en los últimos años he aprendido a hacerlo bien. (es decir, encontré una manera que funcione para mí y para mi equipo ...)
Para mi algunas de esas cosas fueron:
- Encontrar un flujo de trabajo que se adapte a la prueba de la unidad.
- Integrar las pruebas unitarias en mi IDE y tener accesos directos para ejecutar / depurar pruebas.
- Aprendiendo a probar qué. (Por ejemplo, cómo probar el inicio de sesión o el acceso a los archivos. Cómo abstraerse de la base de datos. Cómo realizar simulacros y utilizar un marco de simulacros. Aprenda técnicas y patrones que aumentan la capacidad de prueba).
- Tener algunas pruebas es mejor que no tener ninguna prueba.
- Se pueden escribir más pruebas más adelante cuando se descubre un error. Escriba la prueba que prueba el error, luego corrija el error.
- Tendrás que practicar para ser bueno en eso.
Así que hasta encontrar el camino correcto; Sí, es aburrido, no gratificante, difícil de hacer, consume mucho tiempo, etc.
EDITAR: En esta entrada de blogpost voy a profundizar en algunas de las razones dadas aquí en contra de la prueba de unidad.
"Existen las excusas comunes para no escribir exámenes, pero son solo excusas".
¿Son ellos? Reúna a ocho programadores en una sala, hágales una pregunta sobre la mejor manera de mantener la calidad del código y obtendrá nueve respuestas diferentes, según su edad, educación y preferencias. Los científicos de la computación de la era de la década de 1970 se habrían reído ante la noción de pruebas de unidad; No estoy seguro de que se hayan equivocado.
Código de calidad es impopular? Déjame disputar ese hecho.
Conferencias como Agile 2009 tienen una gran cantidad de presentaciones sobre integración continua y técnicas y herramientas de prueba. Las conferencias técnicas como Devoxx y Jazoon también tienen su parte justa de esos temas. Incluso hay una conferencia entera dedicada a la Integración y Pruebas CITCON ( CITCON , que se realiza 3 veces al año en 3 continentes). De hecho, mi sensación personal es que esas conversaciones son tan comunes, que están a punto de ser totalmente aburridas para mí.
Y en mi experiencia como consultor, la consultoría sobre técnicas y herramientas de calidad de código es bastante fácil de vender (aunque no muy bien pagado).
Dicho esto, aunque creo que la Calidad del Código es un tema popular para discutir, prefiero estar de acuerdo con el hecho de que los desarrolladores (en general) no hacen buenas o suficientes pruebas. Tengo una explicación razonablemente simple a ese hecho.
Esencialmente, se reduce al hecho de que esas técnicas aún son razonablemente nuevas (TDD tiene 15 años, CI tiene menos de 10) y tienen que competir con 1) gerentes, 2) desarrolladores cuyas formas "han funcionado bien hasta ahora" (Lo que sea que eso signifique). En palabras de Geoffrey Moore, las técnicas modernas de Calidad de Código aún se encuentran en una etapa temprana de la curva de adopción. Tomará tiempo hasta que toda la industria los adopte.
Sin embargo, la buena noticia es que ahora me encuentro con desarrolladores recién llegados de la universidad a los que se les ha enseñado TDD y que están realmente interesados en ello. Eso es un desarrollo reciente. Una vez que hayan llegado suficientes al mercado, la industria no tendrá más remedio que cambiar.
Creo que la calidad del código está sobrevalorada. Cuanto más lo hago, menos significa para mí. Los marcos de calidad de código prefieren código demasiado complicado. Nunca ve errores como "este código es demasiado abstracto, nadie lo entenderá", pero por ejemplo, PMD dice que tengo demasiados métodos en mi clase. Por lo tanto, debería dividir la clase en clases / clases abstractas (la mejor forma, ya que a PMD no le importa lo que hago) o cortar las clases según la funcionalidad (la peor manera es que aún podría haber demasiados métodos, ya he estado allí).
El análisis estático es realmente genial, sin embargo, solo son advertencias. Por ejemplo, FindBugs tiene problemas con el lanzamiento y debes usar instaceof para hacer que la advertencia desaparezca. No hago eso solo para hacer feliz a FindBugs.
Creo que el código demasiado complicado no es cuando el método tiene 500 líneas de código, sino cuando el método utiliza otros 500 métodos y muchas abstracciones solo por diversión. Creo que los maestros de la calidad del código deberían realmente trabajar para encontrar cuándo el código es demasiado complicado y no les importan las cosas pequeñas (puede refactorizarlas con las herramientas adecuadas muy rápidamente).
No me gusta la idea de cobertura de código ya que es realmente inútil y hace que la prueba de unidad sea aburrida. Siempre pruebo el código con una funcionalidad complicada, pero solo ese código. Trabajé en un lugar con una cobertura de código del 100% y fue una verdadera pesadilla cambiar algo. Porque cuando cambias algo tienes que preocuparte por pruebas de unidad rotas (mal escritas) y nunca sabes qué hacer con ellas, muchas veces simplemente las comentamos y agregamos todo para corregirlas más tarde.
Creo que la prueba de unidad tiene su lugar y, por ejemplo, realicé muchas pruebas de unidad en el analizador de mi página web, porque siempre encontré diferentes errores o etiquetas no compatibles. Probar los programas de la base de datos es realmente difícil si también quiere probar la lógica de la base de datos, DbUnit es realmente difícil de trabajar.
Es ''aburrido'' captar alguna ''característica'' aleatoria con extrema importancia por más de un día en el misterioso código de la jungla escrito por alguien más hace x años sin ninguna idea de qué está mal, por qué está mal y sin absolutamente ninguna idea qué podría solucionarlo cuando se suponía que terminaría en unas pocas horas. Y cuando se hace, nadie queda satisfecho por causa de gran retraso.
He estado allí - visto eso.
Es bastante simple si consideras el adagio de ingeniería "Bueno, rápido, barato: elige dos". En mi experiencia, el 98% del tiempo, es rápido y barato, y por necesidad el otro debe sufrir.
Es la psicología básica del dolor. Cuando corres para cumplir con un código de fecha límite, la calidad ocupa el último asiento. Lo odiamos porque es aburrido y aburrido.
La administración debe venderse según el valor de gastar más tiempo ahora para ahorrar tiempo en el futuro. Dado que en realidad no pueden medir "errores no solucionados", a menudo les preocupa más cumplir con sus plazos inmediatos y fecha de envío que la calidad a largo plazo del proyecto.
La calidad del código es específica del contexto y es difícil de generalizar, no importa cuánto esfuerzo intente hacerlo la gente.
Es similar a la diferencia entre teoría y aplicación.
La calidad del código es subjetiva. Los temas subjetivos son siempre tediosos.
Dado que el objetivo es simplemente hacer algo que funcione, la calidad del código siempre ocupa el segundo lugar. Añade tiempo y costo. (No estoy diciendo que no debería ser considerado como algo bueno).
El 99% de las veces, no hay consercencias de terceros por la mala calidad del código (a menos que esté haciendo un software de conmutación de trenes o paradas de espacio).
- ¿Funciona? = Concreto.
- Es bonito = En el ojo del espectador.
Lee el mes del hombre mítico de Fred Brooks. No hay bala de plata.
La falta de "calidad del código" no le cuesta al usuario, al vendedor, al arquitecto ni al desarrollador del código; ralentiza la siguiente iteración, pero puedo pensar en varios productos exitosos que parecen estar hechos de pelo y barro.
Considero que las pruebas unitarias me hacen más productivo, pero he visto muchos códigos mal diseñados, ilegibles y mal diseñados que pasaron todas sus pruebas (generalmente un código largo en el diente que había sido parchado muchas veces). Al pasar las pruebas, obtienes un Skoda digno de una carretera, no la destreza de un Bristol . Pero si tiene "baja calidad de código" y pasa sus pruebas y cumple constantemente los requisitos del usuario, entonces ese es un modelo de negocio válido.
Mi conclusión es que los desarrolladores no quieren escribir pruebas.
No estoy seguro. En parte, todo el proceso educativo en software no está guiado por pruebas, y probablemente debería serlo: en lugar de pedir que se realice un ejercicio, entregue las pruebas unitarias a los estudiantes. Es normal en las preguntas de matemáticas realizar una comprobación, ¿por qué no en ingeniería de software?
La otra cosa es que las pruebas unitarias requieren unidades. A algunos desarrolladores les resulta difícil hacer bien la modularización y la encapsulación. Un buen líder técnico creará una arquitectura modular que localiza el alcance de una unidad, lo que facilita la prueba de forma aislada; muchos sistemas no tienen buenos arquitectos que faciliten la prueba de pruebas, o no se refacilicen con suficiente regularidad para reducir el acoplamiento entre unidades.
También es difícil probar aplicaciones distribuidas o controladas por GUI, debido al acoplamiento inherente. Solo he estado en un equipo que lo hizo bien, y que tenía un departamento de pruebas tan grande como un departamento de desarrollo.
El análisis de código estático a menudo se juega en pequeños proyectos, pero en realidad no se utiliza para hacer cumplir las convenciones de codificación o encontrar posibles errores en proyectos empresariales.
Cada conjunto de convenciones de codificación que he visto y que no se ha automatizado ha sido lógicamente inconsistente, a veces hasta el punto de ser inutilizable, incluso las que dicen haber sido utilizadas "con éxito" en varios proyectos. Las normas de codificación no automáticas parecen ser más políticas que documentos técnicos.
Por lo general, se ignoran incluso las advertencias del compilador, como el posible acceso al puntero nulo.
Nunca he trabajado en una tienda donde se toleraron las advertencias del compilador.
La gente no tiene un sentido común de lo que "bueno" significa para el código. Mucha gente bajará al nivel de "Lo ejecuté" o incluso "Lo escribí".
Necesitamos tener algún tipo de sentido compartido de lo que es un buen código y si es importante. Para la primera parte de eso, he escrito algunos pensamientos:
http://agileinaflash.blogspot.com/2010/02/seven-code-virtues.html
En cuanto a si importa, eso ha sido cubierto muchas veces. Importa bastante si tu código va a vivir mucho tiempo. Si realmente nunca se venderá o no se desplegará, entonces claramente no lo hará. Si no vale la pena hacerlo, no vale la pena hacerlo bien.
Pero si no practicas la escritura de código virtuoso, entonces no puedes hacerlo cuando importa. Creo que la gente ha practicado haciendo un trabajo pobre y no sabe nada más.
La probabilidad de que sea reemplazado por un estudiante recién salido de la universidad o empleado externo es más directamente proporcional a la legibilidad de su código.
La prueba unitaria requiere trabajo extra. Si un programador ve que su producto "funciona" (p. Ej., Sin pruebas unitarias), ¿por qué lo hace? Especialmente cuando no es tan interesante como implementar la siguiente función en el programa, etc. La mayoría de las personas tienden a ser perezosas cuando se trata de hacerlo, lo que no es algo bueno ...
La revisión del código no es una ciencia exacta. Metrics utilizadas son de alguna manera discutibles. En algún lugar de esa página: " No puedes controlar lo que no puedes medir "
Supongamos que tiene una función enorme de 5000 líneas con 35 parámetros. Puede realizar una prueba unitaria de cuánto desea, podría hacer exactamente lo que se supone que debe hacer. Cualesquiera que sean las entradas. Entonces, según la prueba de la unidad, esta función es "perfecta". Además de la corrección, hay muchos otros atributos de calidad que es posible que desee medir . Rendimiento, escalabilidad, mantenibilidad, usabilidad y demás. ¿Alguna vez te has preguntado por qué el mantenimiento del software es una pesadilla?
El control de calidad de los proyectos de software real va más allá de simplemente verificar si el código es correcto. Si verifica el modelo V del desarrollo de software , notará que la codificación es solo una pequeña parte de la ecuación completa.
El control de calidad del software puede llegar hasta el 60% del costo total de su proyecto. Esto es enorme En cambio, las personas prefieren recortar al 0% e irse a casa pensando que tomaron la decisión correcta. Creo que la verdadera razón por la que se dedica tan poco tiempo a la calidad del software es porque la calidad del software no se comprende bien.
- ¿Qué hay para medir?
- ¿Como lo medimos?
- ¿Quién lo medirá?
- ¿Qué ganaré / perderé al medirlo?
Muchos de los fabricantes de codificadores no se dan cuenta de la relación entre "menos errores ahora" y "más ganancias después". En cambio, todo lo que ven es "tiempo perdido ahora" y "menos ganancias ahora". Incluso cuando se muestran bonitos gráficos demostrando lo contrario.
Además, el control de calidad del software y la ingeniería del software en su conjunto es una disciplina relativamente nueva. Gran parte del espacio de programación hasta ahora ha sido ocupado por los cibernéticos. ¿Cuántas veces has escuchado que "alguien" puede programar? Cualquiera puede escribir código seguro, pero no todos pueden ser programadores.
EDITAR *
Me he encontrado con este documento (PDF) que es del tipo que dijo "No puedes controlar lo que no puedes medir". Básicamente, está diciendo que controlar todo no es tan deseable como pensó al principio. No es una receta de cocción exacta que pueda aplicar ciegamente a todos los proyectos, como las escuelas de ingeniería de software quieren hacerle pensar. Simplemente agrega otro parámetro para controlar, que es "¿Deseo controlar este proyecto? ¿Será necesario?"
Me recuerda a este sketch de Monty Python :
"¿Emocionante? No, no lo es. Es aburrido. Aburrido. Aburrido. Dios mío es aburrido, es tan aburrido y tedioso y sofocante y aburrido y desdichado TOTAL".
Mucho de esto surge cuando los programadores olvidan, o son ingenuos, y actúan como si su código no fuera visto por otra persona en una fecha posterior (o ellos mismos meses / años más adelante).
Además, comentar no es tan "genial" como escribir un pedazo de código pulido.
Muchos de los conceptos que se enfatizan en la escritura moderna sobre la calidad del código pasan por alto la métrica principal de la calidad del código: el código debe ser funcional ante todo. Todo lo demás es solo un medio para ese fin.
Algunas personas sienten que no tienen tiempo para aprender la última moda en ingeniería de software y que ya pueden escribir códigos de alta calidad. No estoy en un lugar para juzgarlos, pero en mi opinión es muy difícil que su código se use durante largos períodos de tiempo si las personas no pueden leerlo, entenderlo y cambiarlo.
Otra cosa que varias personas han mencionado es que la mayoría de los ingenieros de desarrollo son probadores terribles . No tienen la experiencia ni la mentalidad para probar con eficacia su propio código. Esto significa que las pruebas de unidad no les parecen muy valiosas, ya que todo su código siempre pasa las pruebas de unidad, ¿por qué molestarse en escribirlas?
La educación y la tutoría pueden ayudar con eso, al igual que el desarrollo basado en pruebas. Si primero escribe las pruebas, al menos está pensando principalmente en las pruebas, en lugar de intentar realizar las pruebas, de modo que pueda confirmar el código ...
Respuesta corta: es uno de esos intangibles que solo aprecian otros desarrolladores e ingenieros, principalmente experimentados, a menos que algo salga mal. En qué momento los gerentes y los clientes están alborotados y exigen por qué no se implementaron los procesos formales.
Respuesta más larga: este enfoque miope no se limita al desarrollo de software. La industria automotriz estadounidense (o lo que queda de ella) es probablemente el mejor ejemplo de esto.
También es más difícil justificar los procesos formales de ingeniería cuando los proyectos comienzan su vida como únicos o desechables. Por supuesto, mucho después de que finalice el proyecto, toma vida propia (y se vuelve prominente) a medida que las diferentes unidades de negocios comienzan a depender de él para su propio proceso de negocios.
En qué punto es necesario diseñar una nueva solución; pero sin práctica en el uso de estas herramientas y buenas prácticas, estas herramientas son menos que inútiles. Se convierten en un obstáculo que consume tiempo. Veo esta situación con demasiada frecuencia en compañías donde los equipos de TI son compatibles con el negocio, donde el desarrollo es a menudo reaccionario en lugar de proactivo.
Edit: Por supuesto, estos malos hábitos y muchos otros son la razón real por la que las empresas consultoras como Thought Works pueden continuar prosperando tan bien como lo hacen.
Supongo que la respuesta es la misma que para la pregunta "¿Por qué la calidad del código no es popular?"
Creo que las principales razones son:
- La pereza de los desarrolladores. ¿Por qué invertir tiempo en preparar pruebas unitarias, revisar la solución, si ya está implementada?
- Gestión inadecuada. ¿Por qué pedir a los desarrolladores que se ocupen de la calidad del código, si hay miles de solicitudes de nuevas características y los programadores podrían simplemente implementar algo en lugar de cuidar la calidad de algo que ya está implementado?
Tampoco he visto pruebas de unidad escritas sobre una base regular. La razón de esto se dio porque el código se modificó demasiado al comienzo del proyecto, por lo que todos dejaron de escribir pruebas unitarias hasta que todo se estabilizó. Después de eso todos estaban felices y no necesitaban pruebas de unidad. Así que tenemos algunas pruebas como historial, pero no se utilizan y probablemente no sean compatibles con el código actual.
Personalmente, considero que no es factible escribir pruebas unitarias para grandes proyectos, aunque admito que no lo he probado ni he hablado con personas que lo hicieron. Hay tantas reglas en la lógica de negocios que si simplemente cambia algo un poco un poco, no tiene forma de saber qué pruebas actualizar más allá de las que se bloquearán. Quién sabe, las pruebas anteriores pueden no cubrir todas las posibilidades y lleva tiempo recordar lo que se escribió hace cinco años.
La otra razón es la falta de tiempo. Cuando tiene una tarea asignada donde dice "Tiempo de finalización: O, 5 hombre / día", solo tiene tiempo para implementarla y realizar una prueba superficial, no para pensar en todos los casos y relaciones posibles con otras partes del proyecto y escribir todas las pruebas necesarias Realmente puede tomar 0,5 días para implementar algo y un par de semanas para escribir las pruebas. A menos que se le haya dado específicamente una orden para crear las pruebas, nadie entenderá esa tremenda pérdida de tiempo, lo que resultará en gritos / malas críticas. Y no, para nuestra aplicación empresarial compleja no puedo pensar en una buena cobertura de prueba para una tarea en cinco minutos. Tomará tiempo y, probablemente, un conocimiento muy profundo de la mayoría de los módulos de aplicaciones.
Por lo tanto, los motivos por los que los veo son la pérdida de tiempo, que no proporciona características útiles y la pesadilla de mantener / actualizar las pruebas antiguas para reflejar las nuevas reglas comerciales. Incluso si uno quisiera, solo los colegas experimentados podrían escribir esas pruebas: al menos un año de participación profunda en el proyecto, pero dos o tres son realmente necesarias. Así que los nuevos colegas no manejan las pruebas adecuadas. Y no tiene sentido crear malas pruebas.
Un factor importante que aún no vi mencionado es que cualquier mejora de proceso (pruebas de unidad, integración continua, revisiones de código, lo que sea) necesita tener un defensor dentro de la organización que esté comprometido con la tecnología, tenga la influencia adecuada dentro de la organización , y está dispuesto a hacer el trabajo para convencer a otros del valor.
Por ejemplo, he visto exactamente una organización de ingeniería donde la revisión del código se tomó realmente en serio. Esa compañía tenía un vicepresidente de software que era un verdadero creyente, y él participaba en revisiones de código para asegurarse de que se realizaran correctamente. Incidentalmente, tuvieron la mejor productividad y calidad de cualquier equipo con el que he trabajado.
Otro ejemplo es cuando implementé una solución de prueba de unidades en otra compañía. Al principio, nadie lo usaba, a pesar de la insistencia de la gerencia. Pero varios de nosotros hicimos un verdadero esfuerzo para hablar sobre las pruebas de unidad y para proporcionar la mayor ayuda posible a cualquiera que quisiera comenzar la prueba de unidad. Finalmente, un par de los desarrolladores más respetados se registraron, una vez que comenzaron a ver las ventajas de las pruebas unitarias. Después de eso, nuestra cobertura de pruebas mejoró dramáticamente.
Acabo de pensar en otro factor: algunas herramientas tardan mucho tiempo en comenzar, y ese tiempo de inicio puede ser difícil de conseguir. Las herramientas de análisis estático pueden ser terribles de esta manera: usted ejecuta la herramienta e informa 2,000 "problemas", la mayoría de los cuales son inocuos. Una vez que configura la herramienta correctamente, el problema de falsos positivos se reduce sustancialmente, pero alguien tiene que tomarse ese tiempo y comprometerse a mantener la configuración de la herramienta a lo largo del tiempo.
Una actitud que he conocido con bastante frecuencia (pero nunca de programadores que ya eran adictos a la calidad) es que las pruebas unitarias de escritura solo obligan a escribir más código sin obtener ninguna funcionalidad adicional para el esfuerzo. Y piensan que ese tiempo se dedicaría mejor a agregar funcionalidad al producto en lugar de simplemente crear un "código meta".
Esta actitud generalmente desaparece a medida que las pruebas unitarias detectan más y más errores que, en su opinión, serían serios y difíciles de ubicar en un entorno de producción.
Una respuesta obvia para la parte de desbordamiento de pila es que no es un foro. Es una base de datos de preguntas y respuestas, lo que significa que se intentan evitar las preguntas duplicadas.
¿Cuántas preguntas diferentes sobre la calidad del código se te ocurren? Es por eso que no hay 50,000 preguntas sobre "calidad del código".
Aparte de eso, cualquier persona que diga que los oradores de la conferencia no quieren hablar sobre pruebas de unidad o sobre la calidad del código, claramente tiene que acudir a más conferencias.
También he visto más que suficientes artículos sobre integración continua.
Existen las excusas comunes para no escribir exámenes, pero son solo excusas. Si uno quiere escribir algunas pruebas para su nuevo código, entonces es posible
¿Oh enserio? ¿Incluso si su jefe dice "No le pagaré por perder tiempo en pruebas de unidad"? ¿Incluso si está trabajando en alguna plataforma integrada sin marcos de prueba de unidad? ¿Incluso si está trabajando con un plazo ajustado, tratando de alcanzar algún objetivo a corto plazo, incluso a costa de la calidad del código a largo plazo?
No. No es "siempre posible" escribir pruebas unitarias. Hay muchos muchos obstáculos comunes para ello. Eso no quiere decir que no deberíamos intentar escribir más y mejores pruebas. Solo que a veces, no tenemos la oportunidad.
Personalmente, me canso de las discusiones sobre "calidad del código" porque tienden a
- estar demasiado preocupado por los ejemplos hipotéticos, y con demasiada frecuencia es una idea de algún individuo, que realmente no ha considerado cuán aplicable es a los proyectos de otras personas, o los códigos de diferentes tamaños que el que está trabajando,
- tienden a ser demasiado emocionales e imbuyen nuestro código con demasiados rasgos humanos (piense en el término "olor de código", para un buen ejemplo),
- ser dominado por personas que escriben código abultado, excesivamente complicado y detallado con demasiadas capas de abstracción, o que juzgarán si el código es reutilizable por "parece que puedo tomar este fragmento de código y usarlo en un proyecto futuro" ", en lugar de mucho más significativo" En realidad, he podido tomar este fragmento de código y reutilizarlo en diferentes proyectos ".
Ciertamente estoy interesado en escribir código de alta calidad. Solo tiendo a ser rechazado por las personas que suelen hablar sobre la calidad del código.
Yo diría que por muchas razones.
En primer lugar, si la aplicación / proyecto es pequeño o no lleva datos realmente importantes a gran escala, el tiempo necesario para escribir las pruebas se usa mejor para escribir la aplicación real.
Hay un umbral donde los requisitos de calidad son de un nivel tal que se requieren pruebas de unidad.
También existe el problema de que muchos métodos no son fácilmente verificables. Pueden depender de los datos en una base de datos o similar, lo que crea el dolor de cabeza de configurar los datos de la maqueta para ser alimentados a los métodos. Incluso si configura los datos de la maqueta, ¿puede estar seguro de que la base de datos se comportaría de la misma manera?
La prueba de unidad también es débil para encontrar problemas que no se han considerado. Es decir, la prueba de unidad es mala para simular lo inesperado. Si no ha considerado lo que podría suceder en un corte de energía, si el enlace de la red envía datos erróneos que aún son correctos por CRC. Escribir pruebas para esto es inútil.
Estoy a favor de las inspecciones de código, ya que permiten a los programadores compartir la experiencia y el estilo de código de otros programadores.
Creo que el verdadero problema con la calidad del código o las pruebas es que tienes que trabajar mucho y TÚ no obtienes nada. menos errores == menos trabajo? No, siempre hay algo que hacer. menos errores == más dinero? No, tienes que cambiar de trabajo para obtener más dinero. la prueba de unidad es heroica , solo lo haces para sentirte mejor contigo mismo.
Trabajo en un lugar donde la administración fomenta las pruebas de unidad, sin embargo, soy la única persona que escribe las pruebas (quiero mejorar, es la única razón por la que lo hago) Entiendo que para otros, escribir exámenes es solo un trabajo y no obtienes nada a cambio . Navegar por la web suena mejor que escribir pruebas.
alguien podría romper sus exámenes y decir que no sabe cómo arreglarlo o comentarlo (si usa maven).
Los marcos no están ahí para realizar pruebas de integración de aplicaciones web reales (la prueba unitaria puede pasar, pero puede que no funcione en una página web), por lo que incluso si escribe una prueba, todavía tiene que probarla manualmente.
Puedes usar framework como HtmlUnit , pero es realmente difícil de usar. El selenio se rompe con cada cambio en una página web. La prueba de SQL es casi imposible (puede hacerlo con DbUnit , pero primero debe proporcionar datos de prueba para ello. Los datos de prueba para 5 uniones son mucho trabajo y no hay una manera fácil de generarlos). No sé acerca de su marco web , pero al que estamos usando realmente le gustan los métodos estáticos , por lo que realmente tiene que trabajar para probar el código.
- La pereza / considerado aburrido
- La gerencia siente que es innecesaria - Ignorante actitud de "Solo hazlo bien".
- "Este pequeño proyecto no necesita la gestión de la calidad del código" se convierte en "Ahora sería demasiado costoso implementar la gestión de la calidad del código en este gran proyecto"
Sin embargo, no estoy de acuerdo en que sea aburrido. Un diseño de prueba de unidad sólido hace que la creación de pruebas sea muy fácil y que ejecutarlas sea aún más divertido.
Calculating vector flow control - PASSED
Assigning flux capacitor variance level - PASSED
Rerouting superconductors for faster dialing sequence - PASSED
Running Firefly hull checks - PASSED
Unit tests complete. 4/4 PASSED.
Como todo, puede aburrirse si lo haces demasiado, pero pasar 10 o 20 minutos escribiendo algunas pruebas aleatorias para algunas funciones complejas después de varias horas de codificación no te va a robar la vida creativa.