JUnit: usando constructor en lugar de @Before

Solución:

No, usar el constructor para inicializar su dispositivo de prueba JUnit es técnicamente igual a usar el @Before método (debido al hecho de que JUnit crea una nueva instancia de la clase de prueba para cada @Test). La única diferencia (connotacional) es que rompe la simetría entre @Before y @After, que puede resultar confuso para algunos. En mi humilde opinión, es mejor adherirse a las convenciones (que está utilizando @Before).

Tenga en cuenta también que antes de JUnit 4 y las anotaciones, se dedicaron setUp() y tearDown() métodos – el @Before y @After las anotaciones las reemplazan, pero conservan la lógica subyacente. Por lo tanto, usar las anotaciones también facilita la vida a alguien que migra desde JUnit 3 o versiones anteriores.

Diferencias notables

Más detalles de los comentarios:

• @Before permite anular el comportamiento de la clase principal, los constructores te obligan a llamar a los constructores de la clase principal
• El constructor corre antes de constructores de subclase y @Rule métodos, @Before carreras después todos esos
• Excepciones durante @Before porque @After métodos a llamar, las excepciones en el constructor no

@Before tiene más sentido de usar en ciertos casos porque se llama DESPUÉS del constructor de la clase. Esta diferencia es importante cuando está utilizando un marco simulado como Mockito con anotaciones @Mock, porque su método @Before se llamará después de que se inicialicen los simulacros. Luego puede usar sus simulacros para proporcionar argumentos de constructor a la clase bajo prueba.

Encuentro que este es un patrón muy común en mis pruebas unitarias cuando uso beans colaborativos.

Aquí hay un ejemplo (ciertamente artificial):

@RunWith(MockitoJUnitRunner.class)
public class CalculatorTest {
    @Mock Adder adder;
    @Mock Subtractor subtractor;
    @Mock Divider divider;
    @Mock Multiplier multiplier;

    Calculator calculator;

    @Before
    public void setUp() {
        calculator = new Calculator(adder,subtractor,divider,multiplier);
    }

    @Test
    public void testAdd() {
        BigDecimal value = calculator.add(2,2);
        verify(adder).add(eq(2),eq(2));
    }
}

Prefiero usar constructores para inicializar mis objetos de prueba porque me permite hacer que todos los miembros final para que el IDE o el compilador me diga cuándo constructor olvidé inicializar un miembro y evitar que otro método lo establezca.

EN MI HUMILDE OPINIÓN, @Before viola una de las convenciones más importantes de Java, la de confiar en el constructor para inicializar completamente los objetos.

JUnit 5 también tiene un mejor soporte para la inyección de constructores.

---

---

Utiliza Nuestro Buscador