Esta es la segunda parte de las preguntas y respuestas. Lea la primera parte aquí – Preguntas y respuestas de la entrevista de JUnit (Java Unit Testing) – Parte 1.
Pregunta 1: ¿Qué es Junit?
Respuesta: Java + prueba de unidad = Junit
- Junit es un marco de pruebas de código abierto desarrollado para pruebas unitarias de código java y ahora es el marco predeterminado para probar el desarrollo de Java.
- Ha sido desarrollado por Erich Gamma y Kent Beck.
- Es una interfaz de programación de aplicaciones para desarrollar casos de prueba en java que forma parte de la familia XUnit.
- Ayuda al desarrollador a escribir y ejecutar pruebas automatizadas repetibles.
- Eclipse IDE viene tanto con Junit como con su plug-in para trabajar con Junit.
- Junit también ha sido portado a varios otros lenguajes como PHP, Python, C++ etc.
Pregunta 2: ¿Quién debe usar Junit, los desarrolladores o los probadores?
Respuesta: Utilizado por los desarrolladores para implementar pruebas unitarias en Java. Junit está diseñado para pruebas unitarias, que en realidad es un proceso de codificación, no un proceso de pruebas. Pero muchos probadores o ingenieros de control de calidad también deben utilizar Junit para las pruebas unitarias.
Pregunta3: ¿Por qué utiliza Junit para probar su código?
Respuesta: Junit proporciona un marco de trabajo para lograr todo lo siguiente..:
- Probar temprano y a menudo pruebas automatizadas.
- Las pruebas de Junit se pueden integrar con la construcción, de modo que las pruebas de regresión se pueden realizar a nivel de unidad.
- Reutilización del código de prueba.
- También cuando hay una transferencia las pruebas Junit actúan como un documento para las pruebas de unidad.
Pregunta 4: ¿Cómo se instala Junit?
Respuesta: Veamos la instalación de Junit en la plataforma Windows:
1. Descargue la última versión de Junit de http://download.sourceforge.net/junit/
2. Descomprime el código postal de un directorio de tu elección.
3. Añade JUnit al classpath:
set CLASSPATH=%CLASSPATH%;%JUNIT_HOME%junit.jar
4. Pruebe la instalación ejecutando las pruebas de muestra que vienen junto con Junit ubicado en el directorio de instalación. Por lo tanto, asegúrese de que el directorio de instalación de JUnit está en su CLASSPATH. Luego simplemente escriba:
java org.junit.runner.JUnitCore org.junit.tests.AllTests
Todas las pruebas deberían pasar con un mensaje de «OK». Si las pruebas no pasan, verifica que junit.jar está en el CLASSPATH.
Pregunta 5: ¿Qué son las pruebas de unidad?
Responda: Una prueba unitaria no es más que el envoltorio de código alrededor del código de la aplicación que puede ser ejecutado para ver los resultados de pass – fail.
Pregunta6: ¿Cuándo se escriben las pruebas unitarias en el Ciclo de Desarrollo?
Respuesta: Las pruebas se escriben antes del código durante el desarrollo para ayudar a los codificadores a escribir el mejor código. El desarrollo basado en pruebas es la forma ideal de crear un código libre de errores. Cuando todas las pruebas pasan, ¡sabes que has terminado! Cada vez que una prueba falla o se reporta un error, primero debemos escribir las pruebas unitarias necesarias para exponer el error o los errores, y luego corregirlos. Esto hace casi imposible que ese fallo en particular vuelva a aparecer más tarde.
Pregunta 7: ¿Cómo se escribe una simple clase de prueba de Junit?
Respuesta: Para escribir un caso de prueba, sigue estos pasos:
- Definir una subclase de TestCase.
- Anular el método setUp() para inicializar el/los objeto(s) bajo prueba.
- Opcionalmente, anule el método tearDown() para liberar el/los objeto(s) bajo prueba.
Definir uno o más métodos públicos testXYZ() que ejerciten el/los objeto(s) bajo prueba y afirmar los resultados esperados.
Pregunta8: ¿Qué es Junit TestCase?
Respuesta: JUnit TestCase es la clase base, junit.framework.TestCase, que permite crear un caso de prueba. (Aunque la clase TestCase ya no está soportada en JUnit 4.4.)
Un caso de prueba define la fijación para ejecutar múltiples pruebas. Para definir un caso de prueba
-Implementar una subclase de TestCase
-Definir las variables de instancia que almacenan el estado de la fijación
-Iniciar el estado de fijación anulando la configuración…
-Limpieza después de una prueba anulando el desgarro
Cada prueba se realiza en su propia instalación, así que no puede haber efectos secundarios entre las pruebas.
Pregunta 9: ¿Qué es el TestSuite de Junit?
Respuesta: JUnit TestSuite es una clase de contenedor bajo el paquete junit.framework.TestSuite. Nos permite agrupar múltiples casos de prueba en una colección y ejecutarlos juntos. (JUnit 4.4 no soporta la clase TestSuite ahora).
Pregunta 10: ¿Qué es Junit Test Fixture?
Respuesta: Un Test Fixture es un estado fijo de un conjunto de objetos que se utiliza como línea de base para la ejecución de pruebas. Su propósito es asegurar que haya un entorno bien conocido y fijo en el que se ejecuten las pruebas para que los resultados sean repetibles. Ejemplos de dispositivos de fijación:
- Cargar una base de datos con un conjunto específico y conocido de datos
- Copiar un conjunto específico de archivos conocidos
- Preparación de los datos de entrada y configuración/creación de objetos falsos o simulados
Si un grupo de pruebas comparte las mismas instalaciones, se debe escribir un código de configuración separado para crear la instalación de prueba común. Si un grupo de pruebas requiere diferentes dispositivos de prueba, se puede escribir código dentro del método de prueba para crear su propio dispositivo de prueba.
Pregunta 11: ¿Qué pasa si un método de prueba de Junit es declarado como «privado»?
Respuesta: Si un método de prueba Junit es declarado como «privado», la compilación pasará bien. Pero la ejecución fallará. Esto se debe a que Junit requiere que todos los métodos de prueba sean declarados como «públicos».
Pregunta 12: ¿Qué pasa si un método de prueba de Junit es declarado para devolver «String»?
Respuesta: Si se declara que un método de prueba Junit devuelve «String», la compilación pasará bien. Pero la ejecución fallará. Esto se debe a que Junit requiere que todos los métodos de prueba sean declarados para devolver «Nulo».
Pregunta13: ¿Por qué no usar system.out.println () para la prueba de la unidad?
Respuesta: Depurar el código utilizando system.out.println() conducirá a un escaneo manual de toda la salida cada vez que el programa se ejecute para asegurar que el código está haciendo las operaciones esperadas. Además, a largo plazo, lleva menos tiempo codificar los métodos de Junit y probarlos en nuestros archivos.
Pregunta14: ¿Los métodos Get () y Set () deben ser probados en qué condiciones?
Respuesta: Las pruebas unitarias realizadas en el código java deben ser diseñadas para apuntar a las áreas que podrían romperse. Dado que los métodos set() y get() en tipos de datos simples no es probable que se rompan, no hay necesidad de probarlos explícitamente. Por otro lado, los métodos set() y get() en tipos de datos complejos son vulnerables a la ruptura. Por lo tanto, deben ser probados.
Pregunta 15: ¿En qué condiciones, los métodos Get() y Set() pueden ser dejados fuera de la prueba?
Respuesta: Debería hacer esta prueba para comprobar si una propiedad ya ha sido establecida (en el constructor) en el punto que desea llamar a getX(). En este caso debe probar el constructor, y no el método getX(). Este tipo de prueba es especialmente útil si se tienen múltiples constructores.
Pregunta16: ¿Necesita escribir una clase de prueba para cada clase que necesite ser probada?
Responda: No. No necesitamos escribir una clase de prueba independiente para cada clase que necesite ser probada. Si hay un pequeño grupo de pruebas que comparten un aparato de pruebas común, puede trasladar esas pruebas a una nueva clase de prueba. Si tenéis dos grupos de pruebas que creéis que os gustaría ejecutar por separado, es aconsejable colocarlos en clases de prueba separadas.
Pregunta 17: ¿Cómo se prueba un método «protegido»?
Respuesta: Un método protegido sólo puede ser accedido dentro del mismo paquete en el que se define la clase. Por lo tanto, probar un método protegido de una clase de destino significa que necesitamos definir su clase de prueba en el mismo paquete que la clase de destino.
Pregunta 18: ¿Cómo se prueba un método «privado»?
Respuesta: Un método privado sólo se puede acceder dentro de la misma clase. Por lo tanto, no hay forma de probar un método «privado» de una clase objetivo desde cualquier clase de prueba. Una salida es que se puede realizar la prueba unitaria manualmente o se puede cambiar el método de «privado» a «protegido».
Pregunta 19: ¿Necesita escribir obligatoriamente un método principal () en una clase de prueba de Junit?
Respuesta: No. Pero aún así los desarrolladores escriben el método main() en una clase de caso de prueba JUnit para llamar a un corredor de pruebas JUnit para ejecutar todas las pruebas definidas en esta clase como:
public static void main(String[] args) { junit.textui.TestRunner.run(Calculator.class);}
Dado que se puede llamar a un JUnit runner para ejecutar una clase de caso de prueba como un comando de sistema, no se recomienda utilizar el método explícito main() para un caso de prueba de Junit. junit.textui.TestRunner.run() toma el nombre de la clase de prueba como argumento. Este método encuentra automáticamente todos los métodos de clase cuyo nombre comienza con test. Por lo tanto, dará lugar a los resultados que se mencionan a continuación:
- testCreateLogFile()
- testExiste()
- testGetChildList()
Ejecutará cada uno de los 3 métodos en una secuencia impredecible (por lo tanto, los métodos de casos de prueba deben ser independientes entre sí) y dará el resultado en la consola.
Pregunta 20: ¿Qué sucede si un método de prueba arroja una excepción?
Respuesta: Si escribe un método de prueba que lanza una excepción por sí mismo o por el método que se está probando, el corredor JUnit declarará esa prueba como fallida.
El ejemplo de prueba que se muestra a continuación está diseñado para que la prueba falle lanzando la excepción de IndexOutOfBoundsException no capturada:
import org.junit.*;import java.util.*;public class UnexpectedExceptionTest2 {// arroja cualquier excepción inesperada@Test public void testGet() arroja Excepción { ArrayList emptyList = new ArrayList(); Excepción anyException = null; // no atrapar ninguna excepción Objeto o = emptyList.get(1); }}
Si haces esta prueba, fallará:
SALIDA:
Hubo un fallo:
testGet(UnexpectedExceptionTest2)
java.lang.IndexOutOfBoundsException: Índice: 1, Tamaño: 0
en java.util.ArrayList.RangeCheck(ArrayList.java:547)
en java.util.ArrayList.get(ArrayList.java:322)
en UnexpectedExceptionTest2.testGet(UnexpectedExceptionTest2.ja
at sun.reflect.NativeMethodAccessorImpl.invoke0(Método nativo)
en el sol.reflejo.MétodoNativoAccesorioImplorar.invocar(MétodoNativoActuar
en el sol.reflejo.DelegandoMétodoAccesorioImplorar(DelegandoMe
en java.lang.reflect.Method.invoke(Method.java:597)
en org.junit.internal.runners.TestMethod.invoke(TestMethod.java
en org.junit.internal.runners.MethodRoadie.runTestMethod(Method
en org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.j
at org.junit.internal.runners.MethodRoadie.runBeforesThenTestTh
en org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie
en org.junit.internal.runners.MethodRoadie.run(MethodRoadie.jav
en org.junit.internal.runners.JUnit4ClassRunner.invokeTestMetho
en org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUni
en org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4Cla
en org.junit.internal.runners.ClassRoadie.runUnprotected(ClassR
en org.junit.internal.runners.ClassRoadie.runProtegido(ClassRoa
en org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4Class
en org.junit.internal.runners.CompositeRunner.runChildren(Compo
en org.junit.internal.runners.CompositeRunner.run(CompositeRunn
en org.junit.runner.JUnitCore.run(JUnitCore.java:130)
en org.junit.runner.JUnitCore.run(JUnitCore.java:109)
en org.junit.runner.JUnitCore.run(JUnitCore.java:100)
at org.junit.runner.JUnitCore.runMain(JUnitCore.java:81)
en org.junit.runner.JUnitCore.main(JUnitCore.java:44)
¡¡FALLAS!!
Las pruebas funcionan: 1, Fallas: 1
Pregunta 21: ¿Cuando los objetos son basura recolectada después de la ejecución de una prueba?
Respuesta: Por diseño, el árbol de instancias de la prueba se construye en una sola pasada. Luego las pruebas se ejecutan en una segunda pasada. El corredor de pruebas tiene fuertes referencias a todas las instancias de la prueba durante la duración de la ejecución de la prueba. Esto significa que para una ejecución de prueba muy larga con muchas instancias de prueba, ninguna de las pruebas puede ser basura recogida hasta el final de toda la ejecución de la prueba. Por lo tanto, si en una prueba se asignan recursos externos o limitados, usted es responsable de liberar esos recursos. Establecer explícitamente un objeto a nulo en el método tearDown(), por ejemplo, permite que sea basura recogida antes del final de toda la ejecución de la prueba.
Pregunta22: ¿Qué es la declaración «assert» de Java?
Respuesta: Las aserciones de Java permiten al desarrollador poner declaraciones de «afirmación» en el código fuente de Java para ayudar a la unidad de pruebas y depuración.
Una declaración «assert» tiene el siguiente formato:
assert expresión_booleana: expresión_serie;
Cuando esta sentencia se ejecuta:
- Si la expresión_booleana se evalúa a true, la sentencia pasará normalmente.
- Si la expresión_booleana evalúa a false, la sentencia fallará con una excepción «AssertionError».
Métodos de ayuda que ayudan a determinar si los métodos que se están probando funcionan correctamente o no
- assertEquals([String message], expected, actual) -cualquier tipo de objeto puede utilizarse para comprobar la igualdad- tipos y objetos nativos, también especifican la tolerancia cuando se comprueba la igualdad en caso de números en coma flotante.
- assertNull([String message], java.lang.Objectoobjeto) -afirma que un objeto dado es nulo
- assertNotNull([String message], java.lang.Objectoobjeto) -afirma que un objeto dado no es nulo
- assertTrue([String message], Boolean condition) -Afirma que la condición booleana dada es verdadera
- assertFalse([String message], Boolean condition) -Afirma que la condición booleana dada es falsa
- fail([String message]) -Falla la prueba inmediatamente con el mensaje opcional
Ejemplo..:
public void testSum() { int num1 = 15; int num2 = 50; int total = 35; int sum = 0; sum = num1 + num2; assertEquals(sum, total); }
