M07 - UF2

Preparación y distribución de
aplicaciones
[Parte 1]
TESTING

Hacer pruebas es la forma de asegurarse que lo que queremos que haga nuestro
programa, lo haga, y lo haga sin errores.

Por lo tanto, ¿para qué creeis que sirven las pruebas?

→ Respuesta correcta: Encontrar Errores en el código!

Y ¿Qué tipo de errores?

→ Errores de Codificación
→ Errores de Diseño
→ Errores de Requisitos
…

Importancia del uso de pruebas

¿Creéis que es importante la realización de pruebas?

Aquí tenemos algunos ejemplos que hacen referencia a los errores más bestias
cometidos mediante Software

(http://www.cs.tau.ac.il/~nachumd/horror.html)

- El mal funcionamiento del lanzador de satélites Ariane 5 fue causado por una
rutina de excepción de software defectuosa resultante de una mala
conversión de punto flotante de 64 bits a entero de 16 bits

- Durante el vuelo inaugural del transbordador espacial Discovery, se perdieron

30 segundos de datos de telemetría en tiempo real (no críticos) debido a un
problema en la etapa de requisitos del proceso de desarrollo de software.

- Un misil Scud iraquí alcanzó el cuartel de Dhahran, dejando 28 muertos y 98

heridos. El misil entrante no fue detectado por las defensas Patriot, cuyo reloj
se había desviado .36 segundos durante el asedio continuo de 4 días, y el
error aumentaba con el tiempo transcurrido desde que se encendió el
sistema. Esta falla de software impidió el seguimiento en tiempo real. Las
especificaciones exigían velocidades de los aviones, no misiles Mach 6, para
un rendimiento continuo de 14 horas, no 100. El software parcheado llegó por
vía aérea un día después. De ACM SIGSOFT Software Engineering Notes ,
vol 16, # 3
Pruebas Unitarias - “Unit Testing”

Las pruebas unitarias son pruebas automatizadas que verifican la funcionalidad en

el componente, clase, método o nivel de propiedad.

El objetivo principal de las pruebas unitarias es tomar la pieza más pequeña de

software comprobable en la aplicación, aislarla del resto del código y determinar si
se comporta exactamente como esperamos.

Cada unidad se prueba por separado antes de integrarla!

Pruebas de integración

Pruebas integrales o pruebas de integración son aquellas que se realizan en el

ámbito del desarrollo de software una vez que se han aprobado las pruebas
unitarias y lo que prueban es que todos los elementos unitarios que componen el
software, funcionan juntos correctamente probándolos en grupo. Se centra
principalmente en probar la comunicación entre los componentes y sus
comunicaciones ya sea hardware o software.

Pruebas de Regresión

Las pruebas de regresión son cualquier tipo de pruebas de software con el objeto
de descubrir errores (bugs), carencias de funcionalidad, o divergencias funcionales
con respecto al comportamiento esperado del software, causados por la realización
de un cambio en el programa.

Cada vez que se realizan cambios en un proyecto, es posible que el código

existente ya no funcione correctamente o que se presenten errores no descubiertos
previamente. Este tipo de error se llama regresión.

Para detectar estos defectos, todo el proyecto debe someterse a una regresión: una
nueva prueba completa de un programa modificado, en lugar de una prueba de solo
las unidades modificadas, para garantizar que no se hayan introducido errores con
las modificaciones.

Como se puede deducir, este tipo de pruebas debe ser automatizado porque puede
estar compuesto por decenas o miles de pruebas unitarias, de integración o más.

Una versión menos costosa, podría ser construir pruebas que repliquen las acciones
que provocaron la regresión, y comprueben que han sido corregidos al no volver a
sucederse los errores; además de añadir los test unitarios que aseguren que el
código que ha corregido la regresión funciona correctamente.
Prueba de Estrés

Esta prueba se utiliza normalmente para romper la aplicación. Se va doblando el

número de usuarios que se agregan a la aplicación y se ejecuta una prueba de
carga hasta que se rompe. Este tipo de prueba se realiza para determinar la solidez
de la aplicación en los momentos de carga extrema y ayuda a los administradores
para determinar si la aplicación rendirá lo suficiente en caso de que la carga real
supere a la carga esperada.

Dicho de otra manera; La prueba de estrés empuja los límites funcionales de un

sistema. Se realiza sometiendo el sistema a condiciones extremas, como volúmenes
de datos máximos o una gran cantidad de usuarios simultáneos.

Pruebas de Seguridad

Las pruebas de seguridad se podrían definir como el conjunto de actividades que

validan los servicios de seguridad de una aplicación e identifican posibles fallos y
debilidades.

Muchos proyectos utilizan un enfoque de caja negra para las pruebas de seguridad,
lo que permite a los expertos, sin conocimiento del software, probar la aplicación en
busca de agujeros, fallos, exploit y debilidades.
Definición de Testing

Testing es el proceso de ejecutar un software con la err intención de encontrar unor.

● Un test exitoso es aquel que descubre un nuevo error

● Un test falla si NO encuentra errores
● Un caso de prueba (test case) es bueno si tiene una alta probabilidad de
encontrar un error

Testing NO es el proceso de comprobar que el SW funciona bien.(aunque, al final,

se utilice para ello)

¿Cuándo funciona bien el Software?

→ ¡Cuando el test FALLA!

La importancia de realizar Tests:

Problema
Los programadores reconocen la utilidad de las pruebas, pero ... pocos escriben test
drivers para realizar pruebas de unidad.
¿Por qué ?

La única manera de salir del bucle es… Realizando pruebas de testing!!!

Objetivos del Testing

Objetivo principal: Descubrir errores.

● Cuantos más y más graves, mejor

● Con el menor esfuerzo y tiempo posibles

Segundo objetivo: Minimizar riesgos

● Cumplir requerimientos en la especificación del SW

Y por último: Asegurar la Calidad del producto.

¿Quién participa en el test?

Test manager
● Planifica proyectos y gestiona el grupo de testers
● Controla la evaluación final del proyecto.

ingeniero de Test
● Controla que los tests se realizan y se documentan tal cómo se
especifica en los requerimientos y por el test manager.
● Implementa casos de prueba (test case)

Tester
● Realiza las pruebas y documenta los resultados.

User(usuario)
● Da feedback sobre versiones alfa y beta.
Principios del Testing

Los Testers son los malos de las películas

El Test es una tarea DESTRUCTIVA!

- Llegar a que el programa se encuentre en situaciones límite.
- Conseguir que el sistema falle.
- Encontrar defectos.

Es un elemento crítico dentro de la evaluación de la cualidad del

Software
- Las empresas utilizan de un 40 a un 80% de su tiempo en realizar
pruebas de test.
Continuando con los Principios del testing

• Los defectos más graves son los que impiden al programa cumplir las
especificaciones.

• Planificar la fase de prueba antes de que comience el desarrollo

→ estrategias de prueba:
testing in the small → testing in the large :
de los módulos y en el programa entero!

• No es posible una prueba de test exhaustiva…

• La prueba sólo es una de las actividades de garantía de la calidad (SCA)

– Revisiones técnicas formales y walkthroughs.

– Métricas del software.
– Estándares de desarrollo.
– Programación por contrato.
Tipos de Testing

Caja Negra

Ignoran los mecanismos internos del sistema.

● Se concentran sólo en inputs y outputs

dado un entorno.

● Evalúan el cumplimiento de los

requerimientos funcionales.

Caja Blanca

● Tiene en cuenta la estructura interna del sistema.

● Analiza módulos, funciones, bloques, sentencias, cobertura del código, ...

Caja negra Caja Blanca
- Prueba de Dominio - Caminos básicos (control del
- Validación flujo de ejecución del programa)
- Clases - Cadenas de texto, definiciones,
- de equivalencia uso del software (Data Flow testing)
- Valores límite
- Pairwise testing
- Stress testing
- Regresión
- Pruebas exploratorias
- Pruebas de casos de uso
- Tablas de decisión

Pruebas de unidad (Unit test)

Se testean componentes individuales para comprobar su calidad. El objetivo es

descubrir errores en el diseño y la implementación, incluyendo:

- Estructura de datos
- Lógica y estructura de un componente
- Interfaz de un componente
- Funciones de un componente

¿Qué significa “unidad”? (hay debate!) Algunas definiciones:

- La parte más pequeña que se puede compilar

- Una función o clase aislada
- Algo lo suficientemente pequeño como para ser desarrollado por una única
persona

¿Quiénes son los Unit testers?

- Son los desarrolladores!!!

Pruebas de integración

Un conjunto de componentes (unidades) se testean conjuntamente.

El objetivo es descubrir errores en:

- Diseño y arquitectura del SW

- Integración de funciones y/u operaciones
- Interfaces e interacciones entre componentes

Entonces… ¿Quiénes son los “integration testers”?

- Desarrolladores y/o ingenieros de test

Pruebas de sistema

● Performance testing
Rendimiento (velocidad, I/O, latencia, robustez, escalabilidad, ...) en tiempo
de ejecución.

Objetivos:

- Confirmar y validar los requerimientos de rendimiento

- Detectar problemas de rendimiento en circunstancias determinadas
(stress)

¿Quién hace performance testing?:

- Desarrollador y/o ingenieros de Test (dependiendo del nivel de la

prueba –clase, módulo, paquete, sistema… - )

Las pruebas de sistema tienen que pasar por dos procesos diferentes, verificación y
validación.

● Verificación : Proceso para determinar si los resultados de una fase dada del
desarrollo cumplen los requerimientos establecidos en la fase previa; por
ejemplo, ¿se ajusta el programa al diseño?

→ ¿Estamos construyendo el software correctamente? ← Caja Blanca.

 ● Validación (Acceptance) : Procedimiento de evaluación del SW al final del
desarrollo en busca de errores en cuanto a cumplimiento de los
requerimientos funcionales y no funcionales

→ ¿Estamos construyendo el software correcto? (el que hay que hacer) ← Caja Negra

En las pruebas de validación se testea el sistema (software) entero. Comprueba que

todos los elementos funcionan correctamente para asegurarse que todas las
funciones del sistema (por ejemplo los casos de uso) y el “performance” son los que
se especifican en los requisitos del proyecto.

Objetivos → (Aspectos a testear)

- Funciones del sistema y performance
- Robustez
- Comportamiento en situaciones de estrés
- operaciones de usuario
- integración del Software (Software interno y externo)

Entonces…. ¿Quién hace pruebas de sistema?

→ Los ingenieros de test y los Usuarios!
Pruebas de caja Negra

Caja Negra

Ignoran los mecanismos internos del sistema.

● Se concentran sólo en inputs y outputs

dado un entorno.

● Evalúan el cumplimiento de los

requerimientos funcionales.

Pruebas de partición Equivalente

● Los datos se pueden clasificar en diferentes grupos

● cada grupo es una partición equivalente donde el programa se comporta de
manera “equivalente”
● las particiones se pueden definir utilizando diferentes criterios
○ Valores válidos / no válidos, tipo de procedimiento, etc …

● La prueba de un elemento de la partición equivalente encuentra los mismos

errores en que cualquier partición → Se reduce el número de casos de
prueba.
● Los casos de prueba (test cases) se han de extraer de cada partición
Ejemplo de partición equivalente

- Vamos a suponer un programa que calcula el valor de la siguiente función:

¿Qué clases de equivalencia se tendrían que tener en cuenta? en otras

palabras, ¿qué valores serían válidos y cuáles no?

x< = -2 → Valor válido

entre -2 < x < 1 → valor inválido

1 < = x → válido

Análisis de valores límite:

→ En algunos casos de pruebas, se definen las fronteras del dominio de los datos
de entrada → Se cogen todos los valores frontera y límite entre ambos lados del
valor límite.

Estos valores se complementan juntamente con las particiones equivalentes; por

ejemplo:
Tenemos una condición de entrada de valores por teclado en un rango [a,b]
(por ejemplo valores desde [-3,10] “desde menos 3 hasta 10”)

[-3,-2,-1, 0, 1, 2, 3, 4 ,5, 6, 7 , 8, 9, 10]

Valores para hacer testing:

1) valores internos 0, 4 → 0 siempre es un buen candidato

2) Valores frontera -3, 10
3) valores interiores frontera: -2, 9
4) valores exteriores frontera: -4, 11

Otro ejemplo:

No hay que limitarse a sólo valores numéricos, si no, al concepto en general de los
casos límite.

¿Qué valores podemos probar en un Array / Lista ?

→ insertar un elemento: vacío, un único elemento, array lleno, valor fuera de

rango…

→ Buscar un elemento: Existente y no existente

Otro ejemplo:

Un módulo acepta como inputs de entrada: Nombre, Lista de tallas

Condiciones para Nombre:

- de 2 a 15 caracteres → (1, 2, 3, 14, 15, 16) + (letras)
- caracteres alfabéticos → ( a..z, A..Z, no alfabéticos)
- Se ignoran espacios → (con espacios y sin espacios)

Condiciones para la lista de tallas

- cada una entre 1 y 48 → (talla 0, 1, 2, 47, 48, 49)
- orden creciente → (probar a introducir valores desordenados)
- …
Pairwise testing / (prueba por pares de valores)

● Problema : → Dados P parámetros y n (sub P) valores para cada parámetro,

la combinación de posibilidades de valores sería de: n1, n2,... nP (podría ser
muy grande)

● Pista: → Muchos de los errores se producen al combinar valores entre

variables

● Solución → Testear solamente cada par de valores.

→ Lo único que importa es que aparezca solo una vez cada pareja de
valores posibles
Casos de prueba a partir de casos de uso

Las anteriores técnicas tienen una aplicabilidad limitada a funciones, módulos o

pequeñas partes de una aplicación.

¿Cómo hay que realizar pruebas de grandes partes o de toda la aplicación?

Necesitamos la especificación.

Caso de uso

– Es la forma de especificar requerimientos funcionales.

– Especifica la secuencia de interacciones con el sistema software que proporcionan
un resultado “valioso” a su usuario
– ¿Cómo se expresan?
• Diagramas de caso de uso : the big picture
• Descripción textual según un modelo estándar
• Para cada diagrama de caso de uso, diagramas de actividad.

Ejemplo Cajero automático

Prueba y casos de uso

Flujo básico de eventos:

– Lo que sucede “normalmente”, o más frecuentemente (el caso “bueno”)

Flujos alternativos:
– Casos opcionales, excepcionales o fuera de la norma.

Cada flujo se descompone en una lista de pasos o eventos, en que se explica qué
hace un actor y qué responde a la aplicación (como en un diálogo).
Ejemplo de prueba y casos de uso cajero automático:

• Flujo básico: Retiro de una cantidad preestablecida ($ 10, $ 20, $ 50 o $ 100)

- Condiciones previas: cajero automático en el estado listo, el sistema bancario
central está en línea.
- Iniciar retiro: el cliente inserta la tarjeta bancaria en el lector de tarjetas del cajero
automático
- Verificar tarjeta bancaria: el cajero automático lee el código de cuenta de la banda
magnética y comprueba si es una tarjeta bancaria aceptable.
- Ingrese PIN - El cajero automático solicita el código PIN del cliente (4 dígitos)
- Verifique el código de la cuenta y el PIN para determinar si la cuenta es válida y si
el PIN ingresado es el PIN correcto para la cuenta. Para este flujo, ambos son
válidos.
- Opciones de cajero automático. El cajero automático muestra las diferentes
alternativas disponibles.
El cliente siempre selecciona "Retirar efectivo".
- Ingrese la cantidad
- El cajero automático, la cantidad a retirar. El cliente selecciona un valor
preestablecido ($ 10, $ 20, $ 50 o $ 100).
- Autorización - El cajero automático inicia el proceso de verificación con la Banca
Sistema enviando la ID de la tarjeta, el PIN, el monto y la información de la cuenta
como transacción. El Sistema Bancario responde con la autorización para completar
el efectivo retiro con éxito y actualiza el saldo de la cuenta en consecuencia.
- (Seguir...)
- Dispense - Se dispensa el dinero.
- Tarjeta de devolución: se devuelve la tarjeta bancaria.
- Recibo: el recibo se imprime y se distribuye. El cajero automático también actualiza
el registro interno respectivamente.
- Condiciones posteriores: el caso de uso termina con el cajero automático en el
estado listo.

• Flujos alternos:
- No es una tarjeta válida
- Cajero automático sin dinero
- Fondos insuficientes en el cajero automático para dispensar la cantidad solicitada
- PIN incorrecto
- Sin cuenta / Tipo de cuenta incorrecto (p. Ej., Congelada)
- Fondos insuficientes en la cuenta
- Se alcanzó la cantidad máxima diaria de retiro
- El cliente abandona en cualquier momento
- Inclinación: los sensores ATM detectan una señal de alarma
etc ...
Generación de casos de prueba

1. Encontrar el conjunto completo de escenarios (deberían cubrir todos

los flujos por lo menos, y también quizá combinaciones de flujos)

2. Para cada escenario, identificar al menos un caso de prueba y las

condiciones que permiten que se ejecute

3. Para cada caso de prueba, fijar el valor de los datos

[Fin parte 1 ]
[Parte 2]
Test Driven Development

- ¿Qué es un test?
- Desde el punto de vista de un tester (persona que testea)
- Encontrar errores.
- Desde el punto de vista de un programador…
- Asegurarse de que el código es correcto.

- Por lo tanto, un test también se puede considerar … ?¿?

- Un requisito (Requerimiento), un ejemplo, y hasta se puede considerar
una parte del diseño.

Introducción

El nombre estrictamente correcto sería Example Driven Development.

– Desarrollamos a partir de la definición de los test/ejemplos.

• En la práctica:

– No se trata tanto de realizar tests, sino de diseñar según los requerimientos.

– Pasamos de pensar en implementar tareas a pensar ejemplos adecuados que

eliminen cualquier posible ambigüedad.

– Dividimos los casos de uso en ‘n’ ejemplos hasta que ese número sea suficiente
para describir la tarea sin ambigüedades.

– La implementación de estos pequeños ejemplos nos puede ayudar a que la

arquitectura local de ciertos módulos surja por sí misma.

Continuamente nos preguntamos → ¿Qué queremos que haga el código?

Ventajas de utilizar TDD (Test Driven Definition)

– Software de alta calidad.

– Incrementa la productividad.
– Código altamente reutilizable.
– En el código, escribiremos justo la funcionalidad necesaria sin sobrediseñar
(ya que escribimos el test antes que el código)

– Trabajo en equipo más fácil.

– Mejora la comunicación.

• TDD tiene tres pasos

– Escribir la especificación del requerimiento (ejemplo, test)

• Hay que pensar en cómo sería la API (firma) del SUT (Subject Under Test).
(sujeto bajo prueba)

– Implementar el código según este ejemplo

• Implementar el mínimo necesario para que el test se cumpla (eso nos hace
pensar en otras situaciones, inputs, flujos de ejecución… ).

– Refactorizar para eliminar duplicidad de código y realizar mejoras.

• Eliminar código duplicado, mejorar el diseño, hacer el código más
reutilizable, más legible, etc…
Mock Objects!

Supongamos que tenemos una arquitectura como la siguiente:

*Account → Cuenta bancaria

*AccountService → Ofrece servicios relacionados con Account
*AccountManager → Gestiona los datos de una Base de datos relacionada con
Account.

¿Qué problemas prácticos cree que pueden aparecer si queremos hacer unit-testing
de los métodos de la clase AccountService?

• Necesitamos que las clases que utiliza AccountService estén

implementadas?

• ¿Necesitamos que haya una DB en funcionamiento?

Respuesta → NO!! , lo que necesitamos son MOCK OBJECTS!

Definición: “Mock object is object created to stand in for object that your code will be
collaboraing with. Your code can call methods on the mock object, which will deliver
results as set up by your tests”.

Es un objeto creado para representar un objeto con el que colaborará su código. Tu

código puede llamar a métodos en el objeto simulado, lo que generará resultados
según lo establecido por sus pruebas ”.
• Características de los Mock Objects:

– Sustituyen los objetos con los que interactúa el SUT (Subject under Test).

– Ofrecen una capa de aislamiento.

– No implementan ninguna lógica de funcionamiento (excepto la mínima

imprescindible que necesita el caso de test).

– Son capas vacías que proveen métodos con los que interactúa el SUT (Subject
under Test).

– Son una “mentira”, una fachada.

Ejemplo

Queremos desarrollar código de test (de unidad) por método

AccountService.transfer()

¿Por qué clase necesitamos un mock object?

• AccountManager: Es quien gestiona y necesita una DB que funcione.

Trojan Horse

Expectation: Característica de un mock que comprueba si el comportamiento de un

SUT es el correcto.

– Ejemplos: A través de un mock podemos comprobar si:

• AccountManager llama al método close cada vez que acaba de realizar

una consulta en una base de datos.
• Un método abre un archivo en disco y al final lo cierra.
• (en C++) allocation y deallocation de memoria.
…

Por lo tanto…

¿Cuándo utilizar mock objects?

– El objeto real tiene un comportamiento no determinista.

– El objeto real es difícil de configurar.
– El objeto real es difícil de llevar a un estado (network error)
– El objeto real es lento.
– El objeto real es una API o UI.
– ¡El objeto real todavía no existe!.

volvemos a dar una pincelada a las pruebas de caja blanca.

Pruebas de caja blanca

• Testing que analiza y tiene en cuenta la estructura interna del sistema.

• Analiza módulos, funciones, bloques, sentencias, cobertura del código, ...
Control Flow en pruebas de caja blanca

Tip: Los test casas se generan de manera que …

– Statement coverage: todas las sentencias se ejecutan al menos una vez.

– Decision (branch) coverage: todas las decisiones (p.ej. condicionales-if) toman

los valores true o false.

– Condition coverage: todas las condiciones (predicados) que forman la expresión

lógica de una decisión toman los valores true o false.

– Path coverage: se ejecutan todos los path.

Statement coverage: Ejecutar todas las sentencias

Decision Coverage: Todas las decisiones toman el valor de True o False.

Condition Coverage: Todas las condiciones (predicados) que forman la expresión

lógica de una decisión toman los valores true o false.

Los casos de prueba deben de cubrir con true o false cada una de las condiciones
de la expresión lógica
Path Coverage: Se ejecutan todos los paths

• ¿Por qué?

– Errores lógicos y Aserciones incorrectas son inversamente proporcionales a

la probabilidad de ejecución del path.

– Es probable que un path no testeado contenga errores…

Por lo tanto.. el testing exhaustivo no existe …

Hay 10^14 paths posibles!

Si cada uno se ejecuta en 1ms tardaríamos 3170 años en testear este programa!!
Pasos para realizar path coverage:

– Convertir el código (o unidad) en un flow graph (diagrama de flujo).

– Calcular una medida de la complejidad lógica de la unidad.

– Utilizar la medida para derivar un conjunto “básico” de paths independientes y

definir sus test cases.

• Nota: El conjunto de paths para hacer path coverage ¡NO es único!

Hay una fórmula para saber cuántos arcos y cuántos nodos hay en un path
coverage: V(G) = E – N + 2 donde E = #arcos i N = #nodos a G.

Ejemplo:

• Definimos test cases para ejecutar estos paths, y por tanto parámetros que nos
hagan ejecutar estos paths.
Loop Testing

Loop simple Loop Anidado Loop Concatenado

Loop simple

– Test cases
• Evitar el loop
• Una pasada por el loop
• Dos pasadas por el loop
• m pasadas por el loop m<n
• (n-1), n ​pasadas por el loop (n es el número máximo de pasadas) donde n
es el número máximo posible de pasadas

Pregunta: ¿Este esquema equivale a?

Valores límite por el número de pasadas por el loop

Loops anidados

– Si extendemos el test por el loop simple explosión en el número de tests

– Reducimos el número de tests:
• Empezar con un test simple por el loop más interior, fijando los demás loops
al valor mínimo.
• Testear un loop más externo (como si fuera un loop simple) manteniendo el
número de iteraciones de los loops interiores a valores habituales.
• Continuar hasta testear todos los loops.

[Fin parte 2]
JUnit - Implementación en intellyJ IDEA

1 - Creamos un nuevo proyecto Kotlin; una vez creado, clicamos en la carpeta “src”
y creamos una nueva carpeta (package) y la denominamos testing.

Una vez creado, creamos en ella una nueva java class (testing01.java) y en ella
dentro del a clase escribimos la sentencia: @Test

clicamos en la bombilla y seleccionamos → Add JUnit 5.7.0 , seleccionamos la ruta

por defecto que ha de ser en la que hemos creado el proyecto y aceptamos.
Si todo es correcto, se ha de generar el siguiente import

1. Create and setup a "tests" folder

○ In the Project sidebar on the left, right-click your project and do
New > Directory. Name it "test" or whatever you like.
○ Right-click the folder and choose "Mark Directory As > Test
Source Root".
2. Adding JUnit library
○ Right-click your project and choose "Open Module Settings" or
hit F4. (Alternatively, File > Project Structure, Ctrl-Alt-Shift-S is
probably the "right" way to do this)
○ Go to the "Libraries" group, click the little green plus (look up),
and choose "From Maven...".
○ Search for "junit" -- you're looking for something like
"junit:junit:4.13".
○ Check whichever boxes you want (Sources, JavaDocs) then
hit OK.
○ Keep hitting OK until you're back to the code.
 3. Write your first unit test
○ Right-click on your test folder, "New > Java Class", call it
whatever, e.g. MyFirstTest.
○ Write a JUnit test -- here's mine:
import org.junit.Assert; import org.junit.Test; public class
MyFirstTest { @Test public void firstTest() {
Assert.assertTrue(true); } }
4. Run your tests
○ Right-click on your test folder and choose "Run 'All Tests'".
Presto, testo.
○ To run again, you can either hit the green "Play"-style button
that appeared in the new section that popped on the bottom of
your window, or you can hit the green "Play"-style button in the
top bar.