27. Tutorial de muestra JUnit ¶

Este tutorial intenta explicar el diseño básico, la funcionalidad y el uso del nuevo JUnit Sampler para JMeter. La muestra se introdujo en la versión 2.1.2 de JMeter. Las versiones anteriores no tienen la muestra.

27.1 Diseño ¶

La implementación actual es compatible con la convención y las extensiones estándar de JUnit, como oneTimeSetUp y oneTimeTearDown . Se pueden agregar otras características a pedido. El muestreador funciona como el JavaSampler con algunas diferencias.

En lugar de usar la interfaz de prueba de JMeter, escanea los archivos jar en busca de clases que extiendan la clase TestCase de JUnit . Esto significa cualquier clase o subclase.
Los archivos jar de prueba JUnit se copian en jmeter/lib/junit en lugar de jmeter/lib
JUnit sampler no utiliza pares de nombre/valor para la configuración. El muestreador asume que setUp y tearDown configurarán la prueba correctamente.

Nota: los métodos setUp y tearDown deben declararse públicos para que JMeter pueda usarlos.
El muestreador mide el tiempo transcurrido solo para el método de prueba y no incluye configuración ni desmontaje .
Cada vez que se llama al método de prueba, JMeter pasará el resultado a los oyentes.
El soporte para oneTimeSetUp y oneTimeTearDown se realiza como un método. Dado que JMeter tiene varios subprocesos, no podemos llamar a oneTimeSetUp / oneTimeTearDown de la misma manera que lo hace maven.
El muestreador informa las excepciones inesperadas como errores.

27.2 Funcionalidad ¶

Aquí hay una descripción de la funcionalidad.

Nombre: nombre para la muestra. Esto es lo mismo que todos los muestreadores de JMeter.
Filtro de paquete: proporciona una forma de filtrar las clases por nombre de paquete.
Nombre de la clase: el nombre de la clase a probar. La muestra escaneará los archivos jar en jmeter/lib/ext y jmeter/lib/junit en busca de clases que extiendan el TestCase de JUnit .
Cadena de constructores: una cadena para pasar al constructor de cadenas de la clase de prueba.
Método de prueba: el nombre del método a probar en el muestreador.
mensaje de exito: un mensaje descriptivo que indica lo que significa el éxito.
Código de éxito: un código único que indica que la prueba fue exitosa.
mensaje de error: un mensaje descriptivo que indica lo que significa falla.
Código de falla: un código único que indica que la prueba falló
Mensaje de error: una descripción de los errores
Código de error: algún código para los errores. No necesita ser único
No llamar a configurar y desmontar: configure el muestreador para que no llame a setUp y tearDown . De forma predeterminada, se debe llamar a setUp y tearDown . No llamar a esos métodos podría afectar la prueba y hacerla inexacta. Esta opción debe utilizarse con precaución.

Si el método seleccionado es oneTimeSetUp o oneTimeTearDown , esta opción debe estar marcada.
Agregar error de aserción: De manera predeterminada, el muestreador no agregará las fallas de aserción al mensaje de falla. Para ver el mensaje en el árbol de resultados, marque la opción.
Agregar excepción de tiempo de ejecución: De manera predeterminada, el muestreador no agregará las excepciones al mensaje de error. Para ver el stacktrace, marque la opción

La implementación actual de la muestra intentará crear una instancia utilizando primero el constructor de cadenas. Si la clase de prueba no declara un constructor de cadena, el muestreador buscará un constructor vacío. Ejemplo a continuación:

Ejemplos de constructores ¶

Constructor vacío:

clase pública myTestCase {
  myTestCase público () {}
}

Constructor de cadenas:

clase pública myTestCase {
  public myTestCase(Texto de cadena) {
    super(texto);
  }
}

De forma predeterminada, JMeter proporcionará algunos valores predeterminados para el código y el mensaje de éxito/fallo. Los usuarios deben definir un conjunto de códigos únicos de éxito y falla y usarlos de manera uniforme en todas las pruebas.

27.3 Uso ¶

Aquí hay un breve paso a paso.

Escriba su prueba JUnit y jar las clases
Copie y pegue los archivos jar en el directorio jmeter/lib/junit
Iniciar JMeter
Seleccionar plan de prueba
Haga clic con el botón derecho en Agregar → Grupo de subprocesos
Seleccionar grupo de hilos
Haga clic con el botón derecho en Agregar → Muestreador → Solicitud JUnit
Ingrese mi prueba unitaria en el nombre
Introduce el paquete de tu prueba JUnit
Seleccione la clase que desea probar
Seleccione un método para probar
Ingrese la prueba exitosa en el mensaje de éxito
Ingrese 1000 en el código de éxito
Ingrese la prueba fallida en el mensaje de falla
Ingrese 0001 en el código de falla
Seleccione el grupo de hilos
Haga clic con el botón derecho en Agregar → Oyente → Ver árbol de resultados

Una ventaja del muestreador JUnit es que permite al usuario seleccionar cualquier método de una variedad de pruebas unitarias para crear un plan de prueba. Esto debería reducir la cantidad de código que un usuario necesita escribir para crear una variedad de escenarios de prueba. A partir de un conjunto básico de métodos de prueba, se pueden crear diferentes secuencias y pruebas utilizando la GUI de JMeter.

Por ejemplo:

Plan de prueba1

TestCase1.testImportCliente
TestCase2.testUpdateRandomCustomer
TestCase1.testSelect100
TestCase2.testUpdateOrder
TestCase1.testSelect1000

Plan de prueba2

TestCase1.testImportCliente
TestCase1.testSelect100
TestCase1.testSelect1000
TestCase2.testAdd100Clientes

27.4 Directrices Generales ¶

Aquí hay algunas pautas generales para escribir pruebas JUnit para que funcionen bien con JMeter. Dado que JMeter ejecuta subprocesos múltiples, es importante tener en cuenta ciertas cosas.

Escriba los métodos setUp y tearDown para que sean seguros para subprocesos. Esto generalmente significa evitar el uso de miembros estáticos.
Haga que los métodos de prueba sean unidades discretas de trabajo y no largas secuencias de acciones. Al mantener el método de prueba en una operación discreta, se facilita la combinación de métodos de prueba para crear nuevos planes de prueba.
Evite hacer que los métodos de prueba dependan unos de otros. Dado que JMeter permite la secuenciación arbitraria de métodos de prueba, el comportamiento del tiempo de ejecución es diferente al comportamiento predeterminado de JUnit.
Si un método de prueba es configurable, tenga cuidado con el lugar donde se almacenan las propiedades. Se recomienda leer las propiedades del archivo Jar.
Cada muestra crea una instancia de la clase de prueba, así que escribe tu prueba para que la configuración ocurra en oneTimeSetUp y oneTimeTearDown .
Si selecciona una clase y no aparece ningún método, significa que la muestra tuvo un problema al crear una instancia de la clase de prueba. La mejor manera de depurar esto es agregar algo de System.out a su constructor de clase y ver qué está sucediendo.

Go to top