¿Cómo reutilizar el método y la prueba en JUnit?

Hola, descubrimos la respuesta a lo que necesitas, desplázate y la encontrarás aquí.

Solución:

Dado este extracto de su pregunta:

… en lugar de TestCaseResourceTest1 tengo TestCaseResourceTest2 … Quiero tener un archivo separado para la prueba número 2

… las formas estándar de compartir código entre casos de prueba son:

• Cree un conjunto de pruebas e incluya el código compartido en el conjunto de pruebas (normalmente en @BeforeClass y @AfterClass métodos). Esto le permite (1) ejecutar el código de configuración una vez (por invocación de suite); (2) encapsule el código de instalación/desmontaje compartido y (3) agregue fácilmente más casos de prueba más adelante. Por ejemplo:

  @RunWith(Suite.class)
  @Suite.SuiteClasses(
      TestCaseResourceTest1.class,
      TestCaseResourceTest2.class
  )
  public class TestSuiteClass 
  
      @BeforeClass
      public void setup() 
          beforeFileTest();
      
  
      private void beforeFileTest() throws Exception 
          // ...
      
  
  

• Crear una clase abstracta cuyos padres TestCaseResourceTest1 y TestCaseResourceTest2 y deje que esos casos de prueba llamen al código compartido en el padre (normalmente a través de super() llamadas). Con este enfoque, puede declarar el código compartido predeterminado en el padre y al mismo tiempo permitir que las subclases (1) tengan su propio comportamiento y (2) anulen selectivamente el comportamiento principal/predeterminado

• Cree un corredor JUnit personalizado, defina el comportamiento compartido en este corredor y luego anote los casos de prueba relevantes con @RunWith(YourCustomRunner.class). Más detalles sobre este enfoque aquí

Solo para reiterar lo que han dicho algunos de los otros carteles; este no es un primer paso común, por lo que es posible que prefiera comenzar de manera simple y solo pasar a suites o clases abstractas o ejecutores personalizados si su uso proporciona una razón convincente para hacerlo.

Suponiendo que desea ejecutar exactamente la misma prueba para 2 clases diferentes (y no burlarse de ella como en su código de ejemplo), puede crear una clase de prueba abstracta, que tiene un método abstracto que devuelve una instancia de la clase para ser probado.

Algo en la línea de:

public abstract class TestCaseResourceTest 

  protected abstract TestCaseService1 getServiceToTest();

  @Before
  public void before() throws Exception 
    testCaseService1 = getServiceToTest();
    MockitoAnnotations.initMocks(this);
    beforeFileTest();
  

  @Test
  public void test() 
    // do your test here
  


public class ConcreteTest extends TestCaseResourceTest 
  protected TestCaseService1 getServiceToTest() 
    return new TestCaseService();
  


public class ConcreteTest2 extends TestCaseResourceTest 
  protected TestCaseService1 getServiceToTest() 
    return new DifferentService();
  

Tuve tal situación y fue una señal de un diseño de implementación incorrecto. Estamos hablando de pruebas unitarias puras donde probamos exactamente lo que se implementa en las clases de producción. Si necesitamos pruebas duplicadas, significa que probablemente tengamos una duplicación en la implementación.

¿Cómo lo resolví en mi proyecto?

1. Extrajo la lógica común en la clase de servicio principal e implementó pruebas unitarias para ello.
2. Para los servicios para niños, implementé pruebas solo para un código implementado en particular allí. No más.
3. Implementé una prueba de integración en un entorno real donde ambos servicios estaban involucrados y probados por completo.

Más adelante puedes encontrar los comentarios de otros programadores, tú asimismo tienes la opción de dejar el tuyo si lo crees conveniente.

---

---

Utiliza Nuestro Buscador