Nunca escribí muchas pruebas unitarias, ¿cómo puedo practicar más?

7

Tengo una entrevista próximamente la próxima semana y hay algunas cosas en su lista de responsabilidades para este trabajo de desarrollo de software (el título del puesto de trabajo es vago, dice desarrollador de Java) que me preocupa:

  • características de la prueba unitaria
  • Depurar nuevas características
  • Proporcionar recomendaciones sobre el diseño de casos de prueba (¿qué es esto?)

Estoy preocupado porque en proyectos de software anteriores, no me he molestado en escribir pruebas unitarias. Sé cómo usar JUnit para escribir pruebas en Eclipse y en el proceso, pero es que no tengo mucha experiencia en la escritura de pruebas. Por ejemplo, confío en los datos de la web, que varían mucho entre sí, y los proceso. ¿Cómo puedo escribir casos de prueba para cada tipo de datos? Además, si los datos provienen de una base de datos local, ¿cómo escribiría un caso de prueba que compruebe que los datos de las tablas se están leyendo correctamente?

He usado la función de depuración en Eclipse siempre que pude, pero a veces, cuando accedo a una biblioteca que no viene con el código fuente para (por ejemplo, tarros de terceros comerciales), el paso a la función se detendría. Así que para la mayoría de los casos, simplemente System.out.println para descubrir dónde está ocurriendo el error. ¿Hay algún método mejor?

¿Cómo puedo practicar en el corto período de tiempo para ser un tanto competente en la prueba de unidad de escritura?

    
pregunta javastudent 06.01.2012 - 20:04

3 respuestas

8

La única forma de practicar es simplemente hacerlo. Todavía estoy aprendiendo cómo escribir pruebas efectivas de unidad a mí mismo. Desafortunadamente, necesita horas detrás del volante para tener una idea real de cómo se ven las buenas pruebas unitarias. El único atajo que se me ocurre es trabajar 16 horas al día en lugar de 8 y aprenderás el doble de rápido, pero solo hasta que la fatiga comience.

Pocas cosas que sugiero:

  • Asegúrese de que está trabajando en una tarea que no es crítica en el tiempo. Las presiones de tiempo y la sensación de que debe hacerse de inmediato, es lo que normalmente hace que las personas tomen atajos y, o bien a) no produzcan ninguna prueba, b) produzcan muy poco o c) produzcan pruebas que son muy difíciles de mantener porque usted nunca se tomó el tiempo para refactorizarlos.

  • Enfoque la tarea de escribir pruebas unitarias con los mismos requisitos de calidad de código (si no más estrictos) que el código de producción. Algunas personas piensan que las pruebas unitarias no se están publicando, por lo que no es tan importante seguir las buenas prácticas y luego terminan con pruebas que son muy frágiles y extremadamente difíciles de mantener.

  • Asigne tiempo suficiente no solo para escribir el examen, sino también para cualquier clase de ayudante que haría la vida más fácil para usted (y para otros en su equipo). Desde mi propia experiencia, parece que las personas tienden a tomar atajos cuando escriben pruebas porque ciertas tareas son demasiado largas para codificarlas correctamente y porque se demora aún más en codificar con factores en una biblioteca, terminan copiando / pegando códigos entre proyectos de pruebas unitarias. . Comencé una biblioteca auxiliar de pruebas de unidad para nuestro grupo con la intención de acelerar el desarrollo de futuras pruebas (algunas funciones comunes en la biblioteca: código simple para registrar / verificar acciones de objetos simulados, código para trabajar con archivos para ayudar a las pruebas unitarias que necesidad de alimentar datos externos, enlaces estándar para anular llamadas win32 ...).

  • Adquiera el hábito de practicar TDD donde escribe pruebas antes del código. Al principio, parece que las pruebas unitarias son una gran sobrecarga, pero como debe ejercer el código de producción que acaba de escribir de todos modos, TDD lo compensa porque lo hace increíblemente fácil de verificar la funcionalidad del código de producción, incluso cuando sin considerar todos los beneficios a largo plazo, inmediatamente comenzará a pagar el tiempo que le tomó escribir las pruebas.

Esto describe cómo aprender a escribir buenas pruebas unitarias. Si simplemente quiere "saber" qué es una buena prueba de unidad, hay una serie de libros realmente buenos por ahí. (Comenzaría con El arte de las pruebas unitarias )

    
respondido por el DXM 06.01.2012 - 20:51
0

Crea una clase simple y escribe pruebas unitarias para ello. Solo a través de la práctica podrás entender cómo se hace. Si es necesario, busque ejemplos de pruebas unitarias en proyectos de código abierto o consulte algunos tutoriales en línea para obtener orientación.

¡Buena suerte en tu entrevista!

    
respondido por el Bernard 06.01.2012 - 20:14
0

La comunidad de software está dividida en materia de pruebas unitarias.

Te recomiendo que no escribas pruebas unitarias, en su mayoría son inútiles. Se escriben porque "es una buena práctica", "los equipos / desarrolladores maduros escriben pruebas unitarias" o algún otro dogma de la industria.

Por otra parte, las pruebas de integración o de extremo a extremo son una señal de que el equipo realmente se preocupa por la calidad.

De todos modos, veamos algunos puntos específicos de tu pregunta.

  1. Escritura de pruebas para el código que acepta datos de la web.

Comience con el caso de prueba Happy Path Esta prueba está ahí para mostrar que el código funciona en su escenario básico. Esto es muy útil para validar que los cambios en el código no rompieron la aplicación de manera importante.

Si la lógica que acepta los datos es complicada, escriba la prueba de ruta feliz para todas las ramas principales de esta lógica.

Según mi experiencia, esta prueba se amortiza muy rápidamente, generalmente dentro de las horas posteriores a su escritura. Créeme, esta prueba sigue dando.

Luego puedes escribir una prueba que pruebe que la seguridad funciona y que tu API devuelve 401/403 cuando sea apropiado.

Después de eso, escribe pruebas con datos que omitan los campos requeridos. En muchos casos, puede escribir el código una vez y ejecutarlo con un campo faltante diferente.

  1. datos de prueba

La forma purista de escribir pruebas es escribirlas de manera que creen todos los datos necesarios para la prueba y luego eliminar toda esa información después de la prueba. En la práctica, esto a menudo no es posible y una estrategia popular es hacer un flashback / restaurar la base de datos con regularidad (por ejemplo, una vez al día, o cada vez que ejecute las pruebas).

Las pruebas de la base de datos a menudo asumirán que algunos datos de la línea de base están presentes en la base de datos, esto está bien.

  1. Impresión para 'depuración'.

Es 2016 y la depuración es cada vez más fácil, pero creo que agregar líneas a los registros sigue siendo el camino a seguir cuando no se puede pasar por el código.

    
respondido por el tymtam 06.05.2016 - 13:35

Lea otras preguntas en las etiquetas