unitarias unitaria una tutorial test que pruebas prueba hacer español ejemplos como java unit-testing junit tdd

tutorial - que es una prueba unitaria java



¿Por qué usar JUnit para probar? (11)

Cuando prueba usando algo como System.out, solo está probando un pequeño subconjunto de posibles casos de uso. Esto no es muy completo cuando se trata de sistemas que podrían aceptar una cantidad casi infinita de diferentes entradas.

Las pruebas unitarias están diseñadas para permitirle ejecutar rápidamente pruebas en su aplicación usando un conjunto muy grande y diverso de diferentes entradas de datos. Además, las mejores pruebas unitarias también tienen en cuenta los casos límites, como las entradas de datos que se encuentran justo al borde de lo que se considera válido.

Para un ser humano probar todas estas entradas diferentes podría tomar semanas, mientras que podría tomar unos minutos para una máquina.

Piénselo de esta manera: tampoco está "probando" algo que será estático. Su aplicación probablemente sufra cambios constantes. Por lo tanto, estas pruebas unitarias están diseñadas para ejecutarse en diferentes puntos en el ciclo de compilación o despliegue. Quizás la mayor ventaja es esta:

Si divide algo en su código, lo sabrá en este momento , no después de su implementación, no cuando un verificador de QA detecta un error, no cuando sus clientes lo han cancelado. También tendrá una mejor oportunidad de solucionar el problema inmediatamente , ya que está claro que lo que rompió la parte del código en cuestión probablemente ocurrió desde su última compilación. Por lo tanto, la cantidad de trabajo de investigación requerido para solucionar el problema se reduce en gran medida.

Tal vez mi pregunta es una novata, pero realmente no puedo entender las circunstancias bajo las cuales usaría junit ?

Ya sea que escriba aplicaciones simples o más grandes, las System.out con las declaraciones de System.out y me resulta muy fácil.

¿Por qué crear clases de prueba con JUnit, carpetas innecesarias en el proyecto si todavía tenemos que llamar a los mismos métodos, verificar qué devuelven y luego tenemos una sobrecarga de anotación de todo?

¿Por qué no escribir una clase y probarla de inmediato con System.out pero no crear Test-classes?

PD. Nunca he trabajado en proyectos grandes que estoy aprendiendo.

Entonces, ¿cuál es el propósito?

La principal ventaja de JUnit es que es automatizado en lugar de tener que verificar manualmente sus impresiones. Cada prueba que escriba permanece en su sistema. Esto significa que si realiza un cambio que tiene un efecto secundario inesperado, su prueba lo detectará y fallará en lugar de tener que acordarse de probar todo manualmente después de cada cambio.

Agregué algún otro System.out que NO PUEDE hacer:

  • Haga que cada caso de prueba sea independiente (es importante)

    JUnit puede hacerlo: cada vez que se crea una nueva instancia de caso de prueba y se llama a @Before .

  • Código de prueba separado de la fuente

    JUnit puede hacerlo.

  • Integración con CI

    JUnit puede hacerlo con Ant y Maven.

  • Organice y combine casos de prueba fácilmente

    JUnit puede hacer @Ignore y prueba suite.

  • Resultado fácil de verificar

    JUnit ofrece muchos métodos de Assert ( assertEquals , assertSame ...)

  • El simulacro y el talón te hacen enfocarte en el módulo de prueba.

    JUnit puede hacer: Usar el simulacro y el talón te hacen configurar el accesorio correcto y enfocarte en la lógica del módulo de prueba.

JUnit es un marco de pruebas unitarias para el lenguaje de programación Java. Es importante en el desarrollo impulsado por pruebas, y es uno de los marcos de prueba de una familia de unidades conocidas colectivamente como xUnit.

JUnit promueve la idea de "primero probar y luego codificar", que enfatiza la configuración de los datos de prueba para un fragmento de código que se puede probar primero y luego se puede implementar. Este enfoque es como "probar un poco, codificar un poco, probar un poco, codificar un poco ..." lo que aumenta la productividad del programador y la estabilidad del código del programa, lo que reduce el estrés del programador y el tiempo dedicado a la depuración.

Características JUnit es un marco de código abierto que se utiliza para escribir y ejecutar pruebas.

Proporciona anotación para identificar los métodos de prueba.

Proporciona afirmaciones para probar los resultados esperados.

Proporciona corredores de prueba para ejecutar pruebas.

Las pruebas JUnit te permiten escribir código más rápido, lo que aumenta la calidad

JUnit es elegantemente simple. Es menos complejo y toma menos tiempo.

Las pruebas de JUnit se pueden ejecutar automáticamente y verifican sus propios resultados y brindan retroalimentación inmediata. No es necesario pasar manualmente un informe de los resultados de las pruebas.

Las pruebas JUnit se pueden organizar en suites de prueba que contienen casos de prueba e incluso otras suites de prueba.

Junit muestra el progreso de la prueba en una barra que es verde si la prueba está yendo bien y se vuelve roja cuando falla una prueba.

JUNIT es el método generalmente aceptado por el desarrollador de Java. Cuando pueden proporcionar una entrada esperada similar a la función y decidir en consecuencia que el código escrito está perfectamente escrito o si el caso de prueba falla, entonces también puede ser necesario implementar un enfoque diferente. JUNIT hará que el desarrollo sea rápido y asegurará los 0 defectos en la función.

Tengo una perspectiva ligeramente diferente de por qué se necesita JUnit.

En realidad, puede escribir todos los casos de prueba, pero es engorroso. Aquí están los problemas:

  1. En lugar de System.out , podemos agregar if(value1.equals(value2)) y devolver 0 o -1 o un mensaje de error. En este caso, necesitamos una clase de prueba "principal" que ejecute todos estos métodos y compruebe los resultados y mantenga qué casos de prueba fallaron y cuáles se aprobaron.

  2. Si desea agregar algunas pruebas adicionales, también debe agregarlas a esta clase de prueba "principal". Cambios al código existente. Si desea detectar automáticamente casos de prueba de clases de prueba, entonces necesita usar la reflexión.

  3. El eclipse no detecta todas sus pruebas y su clase principal para ejecutar las pruebas y necesita escribir configuraciones de depuración / ejecución personalizadas para ejecutar estas pruebas. Sin embargo, todavía no ves esas bonitas salidas de color verde / rojo.

Esto es lo que JUnit está haciendo:

  1. Tiene los métodos assertXXX() que son útiles para imprimir mensajes de error útiles de las condiciones y comunicar los resultados a la clase "principal".

  2. La clase "principal" se llama corredor, que es proporcionada por JUnit, por lo que no es necesario que escriba ninguna. Y detecta los métodos de prueba automáticamente por reflexión. Si agrega nuevas pruebas con la anotación @Test , se detectarán automáticamente.

  3. JUnit también tiene integración de eclipse y integración de maven / gradle, por lo que es fácil ejecutar pruebas y no tendrás que escribir configuraciones de ejecución personalizadas.

No soy un experto en JUnit, así que eso es lo que entendí a partir de ahora, añadirá más en el futuro.

Eso no es una prueba, eso es "mirar manualmente la salida" (conocido en el negocio como LMAO). Más formalmente se lo conoce como "buscar manualmente resultados anormales" (LMFAO). (Vea la nota abajo)

Cada vez que cambie el código, debe ejecutar la aplicación y LMFAO para todos los códigos afectados por esos cambios. Incluso en proyectos pequeños, esto es problemático y propenso a errores.

Ahora escale hasta 50k, 250k, 1m LOC o más, y LMFAO cada vez que haga un cambio de código. No solo es desagradable, es imposible: ha aumentado las combinaciones de entradas, salidas, indicadores, condiciones, y es difícil ejercitar todas las ramas posibles.

Peor aún, LMFAO podría significar visitar páginas sobre páginas de la aplicación web, ejecutar informes, analizar millones de líneas de registro en docenas de archivos y máquinas, leer correos electrónicos generados y entregados, verificar mensajes de texto, verificar la ruta de un robot, llenar una botella de soda, agregando datos de cien servicios web, verificando el seguimiento de auditoría de una transacción financiera ... se entiende la idea. "Salida" no significa unas pocas líneas de texto, "salida" significa un comportamiento agregado del sistema.

Por último, las pruebas de unidad y comportamiento definen el comportamiento del sistema. Las pruebas pueden ser ejecutadas por un servidor de integración continua y verificadas para la corrección. Claro, también lo puede hacer System.out s, pero el servidor de CI no va a saber si uno de ellos está equivocado, y si lo hace, son pruebas unitarias, y también podría usar un marco.

No importa cuán buenos creamos que somos, los humanos no son buenos marcos de pruebas unitarias o servidores de CI.

Nota: Como se señaló (groseramente) en los comentarios, LMAO está probando, pero en un sentido muy limitado. No se puede repetir de manera significativa en todo un proyecto o como parte de un proceso. Es similar a desarrollar incrementalmente en un REPL, pero nunca formalizar esas pruebas incrementales.

Las pruebas unitarias garantizan que el código funcione según lo previsto. También son muy útiles para garantizar que el código siga funcionando según lo previsto en caso de que tenga que cambiarlo más adelante para crear nuevas funcionalidades y corregir un error. Tener una cobertura de prueba alta de su código le permite continuar desarrollando características sin tener que realizar muchas pruebas manuales.

Su enfoque manual de System.out es bueno pero no el mejor. Esta es una prueba única que realiza. En la vida real, los requisitos siguen cambiando y la mayoría de las veces se realizan muchos cambios en las funciones y clases existentes. Entonces ... no cada vez que prueba la pieza de código ya escrita.

También hay algunas características más avanzadas que están en JUnit como

Declaraciones afirmativas

JUnit proporciona métodos para probar ciertas condiciones, estos métodos generalmente comienzan con afirmaciones y le permiten especificar el mensaje de error, el resultado esperado y el real

Algunos de estos métodos son

  1. fail([message]) - Permite que la prueba falle. Podría utilizarse para verificar que no se llegue a una determinada parte del código. O tener una prueba de falla antes de implementar el código de prueba.
  2. assertTrue(true) / assertTrue(false) - Siempre será verdadero / falso. Se puede usar para predefinir un resultado de prueba, si la prueba aún no está implementada.
  3. assertTrue([message,] condition) - Comprueba que la condition booleana es verdadera.
  4. assertEquals([message,] expected, actual) - Comprueba si dos valores son iguales (de acuerdo con el método equals si se implementó, de lo contrario se == reference comparison). Nota: Para las matrices, es la referencia que se verifica, y no los contenidos, usar assertArrayEquals([message,] expected, actual) para eso.
  5. assertEquals([message,] expected, actual, delta) - Comprueba si dos valores flotantes o dobles están a una cierta distancia uno del otro, controlados por el valor delta .
  6. assertNull([message,] object) - Comprueba que el objeto es nulo

y así. Vea el Javadoc completo para todos los ejemplos aquí .

Suites

Con los conjuntos de pruebas, en cierto sentido puede combinar múltiples clases de prueba en una sola unidad para que pueda ejecutarlas todas a la vez. Un ejemplo simple, que combina las clases de prueba MyClassTest y MySecondClassTest en una Suite llamada AllTests :

import org.junit.runner.RunWith; import org.junit.runners.Suite; import org.junit.runners.Suite.SuiteClasses; @RunWith(Suite.class) @SuiteClasses({ MyClassTest.class, MySecondClassTest.class }) public class AllTests { }

Escribimos pruebas para verificar la corrección del comportamiento de un programa.

Verificar la corrección del comportamiento de un programa inspeccionando el contenido de los enunciados de salida usando sus ojos es un manual , o más específicamente, un proceso visual .

Podrías argumentar que

La inspección visual funciona , compruebo que el código haga lo que se supone que debe hacer, para estos escenarios, y una vez que puedo ver que es correcto, estamos listos para continuar.

Ahora primero, es genial que estés interesado en si el código funciona o no correctamente. Eso es bueno. ¡Estás adelantado a la curva! Lamentablemente, hay problemas con esto como enfoque.

El primer problema con la inspección visual es que eres un mal accidente de soldadura al no poder volver a verificar la corrección de tu código.

El segundo problema es que el par de ojos utilizado está estrechamente unido con el cerebro del dueño de los ojos. Si el autor del código también posee los ojos utilizados en el proceso de inspección visual, el proceso de verificación de la corrección depende del conocimiento sobre el programa internalizado en el cerebro del inspector visual.

Es difícil que un nuevo par de ojos entre y verifique la corrección del código simplemente porque no están asociados con el cerebro del codificador original. El propietario del segundo par de ojos tendrá que conversar con el autor original del código para comprender completamente el código en cuestión. La conversación como un medio para compartir el conocimiento es notoriamente poco confiable. Un punto que es discutible si el codificador original no está disponible para los nuevos ojos de pareja. En ese caso, el nuevo par de ojos debe leer el código original.

Leer el código de otras personas que no está cubierto por pruebas unitarias es más difícil que leer el código que tiene pruebas unitarias asociadas. En el mejor de los casos, leer el código de otras personas es un trabajo complicado, en el peor de los casos esta es la tarea más turgente en ingeniería de software. Hay una razón por la que los empleadores, cuando anuncian ofertas de empleo, hacen hincapié en que un proyecto es nuevo (o nuevo). Escribir código desde cero es más fácil que modificar el código existente y, por lo tanto, hace que el trabajo publicitado parezca más atractivo para los empleados potenciales.

Con las pruebas unitarias, dividimos el código en sus partes componentes. Para cada componente, establecemos nuestro puesto indicando cómo debe comportarse el programa. Cada prueba de unidad cuenta una historia de cómo esa parte del programa debe actuar en un escenario específico. Cada prueba unitaria es como una cláusula en un contrato que describe lo que debería suceder desde el punto de vista del código del cliente.

Esto significa que un nuevo par de ojos tiene dos líneas de documentación en vivo y precisa sobre el código en cuestión.

Primero tienen el código en sí, la implementación, cómo se hizo el código ; segundo, tienen todo el conocimiento que el codificador original describió en un conjunto de declaraciones formales que cuentan la historia de cómo se supone que debe comportarse este código .

Las pruebas unitarias capturan y describen formalmente el conocimiento que poseía el autor original cuando implementaron la clase. Proporcionan una descripción de cómo se comporta esa clase cuando es utilizada por un cliente.

Tiene razón al cuestionar la utilidad de hacer esto porque es posible escribir pruebas unitarias que son inútiles, no cubren todo el código en cuestión, se vuelven obsoletas o desactualizadas, etc. ¿Cómo nos aseguramos de que las pruebas unitarias no solo imiten sino que mejoren el proceso de un autor enterado y consciente que inspeccione visualmente las declaraciones de salida de sus códigos en tiempo de ejecución? Escriba la prueba unitaria primero y luego escriba el código para hacer que pase la prueba. Cuando hayas terminado, deja que las computadoras ejecuten las pruebas, son rápidas, son geniales para realizar tareas repetitivas, son las más adecuadas para el trabajo.

Asegure la calidad de la prueba revisándola cada vez que toque el código que prueban y ejecute las pruebas para cada compilación. Si una prueba falla, corrígela inmediatamente.

Automatizamos el proceso de ejecución de pruebas para que se ejecuten cada vez que hacemos una compilación del proyecto. También automatizamos la generación de informes de cobertura de código que detalla qué porcentaje de código está cubierto y ejercido por las pruebas. Nos esforzamos por altos porcentajes. Algunas compañías evitarán que los cambios de código se controlen en el control de código fuente si no tienen suficientes pruebas de unidades escritas para describir cualquier cambio en el comportamiento del código. Normalmente, un segundo par de ojos revisará los cambios de código junto con el autor de los cambios. El revisor realizará los cambios para garantizar que los cambios sean comprensibles y suficientemente cubiertos por las pruebas. Por lo tanto, el proceso de revisión es manual, pero cuando las pruebas (unidades y pruebas de integración y posiblemente las pruebas de aceptación del usuario) pasan este proceso de revisión manual, conviértase en parte del proceso de compilación automático. Se ejecutan cada vez que se registra un cambio. Un servidor de integración continua lleva a cabo esta tarea como parte del proceso de compilación.

Las pruebas que se ejecutan automáticamente, mantienen la integridad del comportamiento del código y ayudan a evitar que los cambios futuros en la base de códigos rompan el código .

Finalmente, proporcionar pruebas le permite volver a factorizar de manera agresiva el código porque puede hacer que las mejoras en los códigos grandes sean seguras, ya que sus cambios no rompen las pruebas existentes.

Hay una advertencia para el desarrollo impulsado por prueba y es que debe escribir el código con el objetivo de hacerlo comprobable. Esto implica la codificación de interfaces y el uso de técnicas como Dependency Injection para crear instancias de objetos colaboradores. Echa un vistazo al trabajo de Kent Beck que describe TDD muy bien. Buscar codificación en interfaces y estudiar patrones de diseño

JUNIT: OBSERVAR Y AJUSTAR

Aquí está mi perspectiva de JUNIT.

JUNIT se puede usar para,
1) Observe un comportamiento del sistema cuando se agrega una nueva unidad en ese sistema.
2) Realice ajustes en el sistema para recibir la unidad "nueva" en el sistema.
¿Qué? Exactamente.

La vida real, por ej.

Cuando su pariente visita la habitación de su albergue universitario,
1) Harás como que eres más responsable.
2) Mantendrá todas las cosas donde deberían estar, como los zapatos en el zapatero, no en la silla, la ropa en el armario, no en la silla.
3) Te desharás de todo el contrabando.
4) comenzará la limpieza en cada dispositivo que posea.

En términos de programación

Sistema: su código
UNIDAD: nueva funcionalidad.
Como el marco JUNIT se usa para el lenguaje JAVA, entonces JUNIT = JAVA UNIT (puede ser).

Supongamos que ya tiene un código a prueba de balas, pero surgió un nuevo requerimiento y debe agregar el nuevo requisito en su código. Este nuevo requisito puede romper su código para alguna entrada (testcase).

Una manera fácil de adaptar este cambio es usando pruebas unitarias (JUNIT).
Para eso, debes escribir varios testcases para tu código cuando estés construyendo tu base de código. Y siempre que llega un nuevo requisito, solo ejecuta todos los casos de prueba para ver si falla algún caso de prueba. Si no, entonces eres un artista BadA ** y estás listo para implementar el nuevo código.
Si alguno de los casos de prueba falla, entonces cambie su código y vuelva a ejecutar los casos de prueba hasta que obtenga el estado verde.

No puede escribir ningún caso de prueba sin utilizar el marco de prueba o tendrá que escribir su framewok de prueba para dar justicia a sus casos de prueba. Aquí hay información sobre JUnit Framework aparte de eso, puedes usar TestNG framework.

Que es Junit?

Junit es un framework de pruebas ampliamente utilizado junto con Java Programming Language. Puede utilizar este marco de automatización para pruebas de unidades y pruebas de UI. Nos ayuda a definir el flujo de ejecución de nuestro código con diferentes Anotaciones. Junit se basa en la idea de "primero probar y luego codificar", lo que nos ayuda a aumentar la productividad de los casos de prueba y la estabilidad del código.

Características importantes de Junit Testing -

  1. Es un marco de prueba de código abierto que permite a los usuarios escribir y ejecutar casos de prueba de manera efectiva.
  2. Proporciona varios tipos de anotaciones para identificar métodos de prueba.
  3. Proporciona diferentes tipos de afirmaciones para verificar los resultados de la ejecución del caso de prueba.
  4. También le da a los corredores de prueba la posibilidad de ejecutar pruebas de manera efectiva.
  5. Es muy simple y, por lo tanto, ahorra tiempo.
  6. Proporciona formas de organizar sus casos de prueba en forma de trajes de prueba.
  7. Da resultados de casos de prueba de manera simple y elegante.
  8. Puede integrar jUnit con Eclipse, Android Studio, Maven & Ant, Gradle y Jenkins