JUnit 5 – Pierwsze kroki

Dziś pobawimy się najprostszymi testami JUnit 5. Samo tworzenie i uruchamianie testów nie różni się w znaczący od wersji 4. Przynajmniej z punktu widzenia użytkownika. Tworzymy test, odpalamy mavena albo też naciskamy Alt+Shift+F10 Enter i gotowe. Jest jednak kilka drobnych, acz znaczących różnic, jeżeli chcemy skorzystać z czegoś więcej. Na przykład przygotować konfiguracje do testu.

Test referencyjny w JUnit 4

Poniżej test JUnit 4, który stanowi punkt odniesienia dla kodu pisanego z użyciem JUnit 5. Nie jest to najlepszy możliwy test, ale nie chciałem zaśmiecać go niepotrzebnymi elementami np. dodatkowymi asercjami.

Listing 1. Testy napisane z użyciem JUnit4

public class FizzBuzzJUnit4WithoutRunnersTest {

	private FizzBuzz sut;

	@BeforeClass
	public static void classSetup() {
		Logger.getLogger("JUnit 4").info("Started at " + LocalDateTime.now());
	}

	@AfterClass
	public static void classTeardown() {
		Logger.getLogger("JUnit 4").info("Finished at " + LocalDateTime.now());
	}

	@Before
	public void setup() {
		sut = new FizzBuzz();
	}

	@Test
	public void shouldReturnFizzBuzzIfDiv3And5() throws Exception {
		assertEquals("FizzBuzz", sut.fizzBuzz(15));
	}

	@Test
	public void shouldReturnBuzzIfDiv5() throws Exception {
		assertEquals("Buzz", sut.fizzBuzz(5));
	}

	@Test
	public void shouldReturnFizzIfDiv3() throws Exception {
		assertEquals("Fizz", sut.fizzBuzz(3));
	}

	@Test
	public void shouldReturnVal() throws Exception {
		assertEquals("2", sut.fizzBuzz(2));
	}
}

Mamy tu cztery metody testowe oraz metodę setup, która będzie wykonywać się przed każdym testem. Dodatkowo mamy dwie metody classSetup i classTeardown, które są uruchamiane przed utworzeniem instancji klasy testowej. Co dokładnie tu się dzieje, to nie jest istotne.

Zmiany w JUnit 5

JUnit 5 wprowadził kilka drobnych zmian w nazewnictwie adnotacji. Nowe adnotacje znacznie lepiej opisują, co się dzieje. Nasza klasa testowa po traktowaniu JUnit 5 będzie wyglądać w następujący sposób:

Listing 2. Testy napisane z użyciem JUnit 5

public class FizzBuzzJUnit5Test {

	private FizzBuzz sut;

	@BeforeAll
	static void classSetup() {
		Logger.getLogger("JUnit 4").info("Started at " + LocalDateTime.now());
	}

	@AfterAll
	static void classTeardown() {
		Logger.getLogger("JUnit 4").info("Finished at " + LocalDateTime.now());
	}

	@BeforeEach
	public void setup() {
		sut = new FizzBuzz();
	}

	@Test
	public void shouldReturnFizzBuzzIfDiv3And5() throws Exception {
		assertEquals("FizzBuzz", sut.fizzBuzz(15));
	}

	@Test
	public void shouldReturnBuzzIfDiv5() throws Exception {
		assertEquals("Buzz", sut.fizzBuzz(5));
	}

	@Test
	public void shouldReturnFizzIfDiv3() throws Exception {
		assertEquals("Fizz", sut.fizzBuzz(3));
	}

	@Test
	public void shouldReturnVal() throws Exception {
		assertEquals("2", sut.fizzBuzz(2));
	}
}

I tak oto adnotacja @Before została zastąpiona przez @BeforeEach, a @BeforeClass przez @BeforeAll. Podobnie ma się sprawa z adnotacjami @After*

Oczywiście nie jest to jedyna zmiana.

Wyłączanie testów

W JUnit 4 wyłączenie testu polegało na dodaniu adnotacji @Ignore:

Listing 3. Przykład wyłączonego testu JUnit 4

@Test
@Ignore
public void shouldReturnVal() throws Exception {
	assertEquals("2", sut.fizzBuzz(2));
	assertEquals("8", sut.fizzBuzz(8));
	assertEquals("11", sut.fizzBuzz(11));
}

O ile w przypadku adnotacji @Before*/@After* można było domyślić się jaka jest intencja użytkownika, to już w przypadku adnotacji @Ignore, jest znacznie gorzej.

Test ignorowany, czyli co?

Kilka razy miałem w różnych zespołach rozmowę na ten temat. Czy jeżeli test jest ignorowany, to można go wywalić? Czy oznacza to, że można zignorować jego rezultaty? A może coś jeszcze innego? Zazwyczaj kończyło się wdrożeniem kolejnego, świetnego, i oczywistego schematu nazywania testów, który umożliwia ich filtrowanie. Żeby było zabawniej, schematy nazewnicze średnio działają z metodami, co prowadzi do tworzenia „kontenerów na testy ignorowane”. Klas, które zawierają testy, ale wszystkie są wyłączone… no właśnie, wyłączone.

Oczywiście intencja programisty, który użył tej adnotacji jest zupełnie inna. Chce on wyłączyć test. Z jakiegoś powodu test nie powinien być uruchamiany. Nie oznacza to, że będzie on pomijany. Po prostu w danym momencie chcemy nie uruchamiać danego testu. W tym celu możemy użyć adnotacji @Disable:

Listing 4. Przykład wyłączonego testu JUnit 5

@Test
@Disable
public void shouldReturnVal() throws Exception {
	assertEquals("2", sut.fizzBuzz(2));
	assertEquals("8", sut.fizzBuzz(8));
	assertEquals("11", sut.fizzBuzz(11));
}

Intencja jest teraz oczywista. Test został wyłączony.

Podsumowanie

JUnit 5 nie zmienia sposobu pisania testów w jakiś drastyczny sposób. Nie na tym podstawowym, prostym poziomie. Zmiany, które wprowadza, są subtelniejsze. Nowe nazewnictwo znacznie lepiej opisuje intencje stojące za poszczególnymi fragmentami kodu. Tym samym ułatwia nam czytanie testów i ich zrozumienie. W połączeniu z innymi mechanizmami, które omówię w kolejnych wpisach, daje nam nowe możliwości w tworzeniu kodu testowego.

Napisz odpowiedź

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

To create code blocks or other preformatted text, indent by four spaces:

    This will be displayed in a monospaced font. The first four 
    spaces will be stripped off, but all other whitespace
    will be preserved.
    
    Markdown is turned off in code blocks:
     [This is not a link](http://example.com)

To create not a block, but an inline code span, use backticks:

Here is some inline `code`.

For more help see http://daringfireball.net/projects/markdown/syntax