junit post updated

Author: maciej-nowak

_drafts/2019-01-07-testy_jednostkowe.md

@@ -113,7 +113,7 @@ Projektowanie przypadków testowych oparciu o `klasy równoważności` polega na
 Testowanie `przejść między stanami` analizuje dozwolone i niedozwolone przejścia między stanami aplikacji za pomocą `automatu skończenie stanowego`. Analizując diagram lub tabelę stanową można zaprojektować testy w taki sposób by pokryły wszystkie przejścia, konkretny ciąg czy testowały przejścia zabronione.
 
 >Diagram stanów wraz z możliwymi przejściami dla kosztów dostawy ukazany jest poniżej.
-![Diagram stanów](/assets/img/diagrams/testing/flow_states.svg){: .center-image }
+![Diagram stanów](/assets/img/diagrams/testing/unit_test_flow_states.svg){: .center-image }
 
 Testowanie z użyciem `tabeli decyzyjnych` polega na sprawdzeniu działania jednostki testowanej w odniesieniu do kombinacji warunków wejściowych znajdujących się w tabeli.
 

_drafts/2019-01-14-junit.md

@@ -5,48 +5,223 @@ date:  2019-01-14
 categories: ["Testowanie"]
 image: testing/junit
 description: "JUnit"
-keywords: "testowanie, testing, testy, jednostkowe, automatyczne, lokalne, zaślepka, atrapa, unit test, mock, stub, przypadki testowe, pokrycie kodu, code coverage, przypadki testowe, junit, roboelectric, mockito, android, programowanie, programming"
+keywords: "testowanie, testing, testy, jednostkowe, automatyczne, lokalne, before, after, rule, zaślepka, atrapa, unit test, mock, stub, przypadki testowe, pokrycie kodu, code coverage, przypadki testowe, klasa testowa, metoda testowa, junit, roboelectric, mockito, android, programowanie, programming"
 ---
 
 ## Integracja
 `Android Studio` ułatwia proces testowania dzięki integracji z bibliotekami wspomagającymi testowanie oraz dostarczeniu dedykowanych narzędzi. Dodając odpowiednie zależności `AndroidX` do projektu już za pomocą kilku kliknięć można wykorzystać możliwości takich bibliotek jaki: `JUnit`, `Mockito`, `Espresso`, `Robolectric` czy `UI Automator`. Lokalne testy jednostkowe uruchamiane na maszynie lokalnej `JVM` znajdują się w lokalizacji: `moduleName/src/test/java/` natomiast instrumentalne testy jednostkowe przeznaczone do uruchamiania na urządzeniu lub emulatorze znajdują się w: `moduleName/src/androidTest/java/`. W przypadku testów instrumentalnych przeznaczonych dla różnych wariantów budowania aplikacji ścieżka zmienia się na: `moduleName/src/androidTestBuildVariantName/java/`.
 
-//TODO photo
+![Rysunek struktury folderu](/assets/img/diagrams/testing/junit_folders.png){: .center-image }
 
 ## Tworzenie i uruchamianie
 `Testy jednostkowe` można tworzyć dodając klasy do odpowiednich folderów lub za pomocą skrótu `Ctrl+Shift+T` kierując kursor na klasę lub metodę. Uruchamianie i analiza następuje z poziomu narzędzia GUI lub konsoli w Android Studio, które umożliwia m.in. eksport wyników testów, przeglądanie statystyk oraz pokrycie kodu.
 
-//TODO photo
+![Rysunek pokrycia kodu](/assets/img/diagrams/testing/junit_coverage.png){: .center-image }
 
 ## Motywacja
 Podstawą procesu testowania jest tworzenie i wykonywanie testów jednostkowych, które odpowiednio napisane w łatwy i wiarygodny sposób weryfikują poprawności logiki jednostki testowanej. Wykonywanie testów jednostkowych przy każdym przyroście ułatwia szybkie wyłapanie błędu. Należy jednak pamiętać o izolacji testowanej jednostki od pozostałych zależności. `JUnit` w Android jest wykorzystywany przede wszystkim do pisania `lokalnych testów` jednostkowych lub prostych `testów instrumentalnych` dla których można dostarczyć zależności (własne lub przy pomocy biblioteki np. Mockito). W pozostałych sytuacjach należy wykorzystać bibliotekę dostarczają zależności środowiska uruchomieniowego np. `Robolectric`.  Tworzenie asercji może zostać usprawnione przez wykorzystanie `Hamcrest`. Alternatywą dla implementacji JUnit dla Android jest wykorzystanie biblioteki `Truth` we współpracy z asercjami Android.
 
 ## Dobre praktyki
-Tworząc metody testowe należy przede wszystkim pamiętać o wykluczeniu wszelkich zależności w taki sposób, aby na wynik testu testowanej jednostki nie miały wpływu inne zależności. Klasy testowe powinny znajdować się w pakiecie o tej samej nazwie co klasy implementacji, a nazwy klas testowych powinny być podobne do klas testowanych. Metody opisowe powinny być nazywane w sposób opisowy i jednoznaczny w nawiązaniu do celu testu nawet jeśli z tego powodu nazwa metody jest długa. W tym celu można posłużyć się konwencją `BDD: Given/When/Then`. Ponadto należy dążyć do minimalizacji asercji, czasu wykonywania testów oraz zwiększać pokrycie kodu. Testy powinny być krótkie, proste i ściśle dotyczyć jednej jednostki. Jeśli sytuacja tego wymaga należy wykorzystywać metody cyklu życia testów, aby zapewnić odpowiednią inicjalizację i czyszczenie środowiska.
+Tworząc metody testowe należy przede wszystkim pamiętać o wykluczeniu wszelkich zależności w taki sposób, aby na wynik testu testowanej jednostki nie miały wpływu inne zależności. Klasy testowe powinny znajdować się w pakiecie o tej samej nazwie co klasy implementacji, a nazwy klas testowych powinny być podobne do klas testowanych. Metody opisowe powinny być nazywane w sposób opisowy i jednoznaczny w nawiązaniu do celu testu nawet jeśli z tego powodu nazwa metody jest długa. W tym celu można posłużyć się konwencją `Given/When/Then`, gdzie `Given` określa warunki początkowe, `When` opisuje akcje, a `Then` informuje o oczekiwanym rezultacie. Ponadto należy dążyć do minimalizacji asercji, czasu wykonywania testów oraz zwiększać pokrycie kodu. Testy powinny być krótkie, proste i ściśle dotyczyć jednej jednostki. Jeśli sytuacja tego wymaga należy wykorzystywać metody cyklu życia testów, aby zapewnić odpowiednią inicjalizację i czyszczenie środowiska.
 
 ## Klasa testowa
 Testy w JUnit (metody) zawierają się w `klasie testowej`, które z kolei mogą być częścią `zestawu klas testowych`. Aby klasa była klasą testową w JUnit4 musi zawierać deklarację przynajmniej jednej metody testowej oznaczonej adnotacją `@Test`. Podstawowym elementem testów są asercje sprawdzające wartość logiczną, równość wartości czy referencji.
 
-//TODO klasa z jedna metoda i roznymi asercjami
+{% highlight kotlin %}
+class SmallTest {
+
+    @Test
+    fun startGameWithDifferentTeamsSize() {
+        val game = Game()
+        game.addPlayer(Game.Team.RED, "Johnnie")
+        game.addPlayer(Game.Team.BLUE, "Jack")
+        game.addPlayer(Game.Team.BLUE, "Jim")
+        game.start()
+        assertFalse(game.hasStarted())
+    }
+}
+{% endhighlight %}
 
 ## Cykl życia
 Klasy testowe poza metodami testowymi mogą składać się także z metod inicjalizacyjnych i końcowych. Metoda oznaczona adnotacją `@Before` wykonywana jest przed każdym testem i służy przygotowaniu środowiska testowego, natomiast z adnotacją `@After` po każdym teście co wykorzystywane jest do czyszczenia środowiska. W analogiczny sposób działają metody oznaczone jako `@BeforeClass` oraz `@AfterClass`, które wykonują się kolejno przed i po uruchomieniu wszystkich testów. Jeśli metoda testowa ma zostać wyłączona z testów należy użyć adnotacji `@Ignore`. Adnotacja `@Test` może zostać wzbogacona o maksymalny czas wykonania (`timeout`) lub oczekiwany typ wyjątku.
 
-//TODO klasa z calym cyklem i ignore i test
+{% highlight kotlin %}
+class FullTest {
+    
+    //mock some dependencies
+    val game = Game()
+    
+    @Before
+    fun init() {
+        //clear game before every test
+        game.clearTeams()
+    }
+
+    @After
+    fun uninit() {
+        //clear game before every test
+        game.stop()
+    }
+    //use @BeforeClass, @AfterClass in the same way
+
+    @Ignore //ignore this test temporary
+    fun startGameWithDifferentTeamsSize() {
+        game.addPlayer(Game.Team.RED, "Johnnie")
+        game.addPlayer(Game.Team.BLUE, "Jack")
+        game.addPlayer(Game.Team.BLUE, "Jim")
+        game.start()
+        assertFalse(game.hasStarted())
+    }
+
+    @Test(timeout = 1000) //after 1000ms when test couldn't finished than just failed
+    fun startAndStopGame() {
+        game.addPlayer(Game.Team.RED, "Johnnie")
+        game.addPlayer(Game.Team.RED, "William")
+        game.addPlayer(Game.Team.BLUE, "Jack")
+        game.addPlayer(Game.Team.BLUE, "Jim")
+        game.start()
+        assertTrue(game.hasStarted())
+        game.stop()
+        assertFalse(game.hasStarted())
+    }
+
+    @Test
+    fun modifyTeamsAndStartGame() {
+        game.addPlayer(Game.Team.RED, "Johnnie")
+        game.addPlayer(Game.Team.RED, "William")
+        game.addPlayer(Game.Team.BLUE, "Jack")
+        game.start()
+        assertFalse(game.hasStarted())
+        game.removePlayer("William")
+        game.start()
+        assertTrue(game.hasStarted())
+    }
+}
+{% endhighlight %}
 
 ## Parametry
-Klasa testowa może posiadać także jedną metodę generującą zestawy danych dla metod testowych. Klasa ta musi być oznaczona adnotacją `@RunWith(Parameterized.class)` natomiast metoda zwracająca kolekcje danych oraz pola przyjmujące wstrzyknięte wartości są oznaczone jako `@Parameter`. Pola mogą przyjmować wstrzykniętą wartość również za pomocą konstruktora.
-
-//TODO przyklad z parametrami
+Klasa testowa może posiadać także jedną metodę generującą zestawy danych dla metod testowych. Klasa ta musi być oznaczona adnotacją `@RunWith(Parameterized.class)` natomiast metoda statyczna zwracająca kolekcje danych oznaczone jako `@Parameters`. Właściwości mogą przyjmować wstrzykniętą wartość za pomocą konstruktora lub być zdefiniowane w ciele klasy i oznaczone jako @Parameter(number).
+
+{% highlight kotlin %}
+@RunWith(Parameterized::class)
+class ParameterizedTest(val redGoals: Int, val blueGoals: Int, val scores: String) {
+
+    companion object {
+        val game = Game()
+
+        @BeforeClass @JvmStatic
+        fun initTeams() {
+            game.addPlayer(Game.Team.RED, "Johnnie")
+            game.addPlayer(Game.Team.RED, "William")
+            game.addPlayer(Game.Team.BLUE, "Jack")
+            game.addPlayer(Game.Team.BLUE, "Jim")
+        }
+
+        @AfterClass @JvmStatic
+        fun uninitTeams() {
+            game.clearTeams()
+        }
+
+        //create test data
+        @Parameters @JvmStatic
+        fun createData(): Collection<Array<Any>> {
+            return listOf(
+                arrayOf(0, 2, "RED 0:2 BLUE"),
+                arrayOf(10, 5, "RED 10:5 BLUE"),
+                arrayOf(3, 3, "RED 3:3 BLUE"))
+        }
+    }
+
+    //use auto parameterized test method
+    @Test
+    fun scoreAndCheckResultWithParameterized() {
+        game.start()
+        repeat(redGoals) { game.goal(Game.Team.RED) }
+        repeat(blueGoals) { game.goal(Game.Team.BLUE) }
+        assertEquals(scores, game.getScore())
+        game.stop()
+    }
+
+    //instead of manual parameterized
+    @Test
+    fun scoreAndCheckResultNormal() {
+        //first test
+        game.start()
+        repeat(2) { game.goal(Game.Team.BLUE) }
+        assertEquals("RED 0:2 BLUE", game.getScore())
+        game.stop()
+
+        //second test
+        game.start()
+        repeat(10) { game.goal(Game.Team.RED) }
+        repeat(5) { game.goal(Game.Team.BLUE) }
+        assertEquals("RED 10:5 BLUE", game.getScore())
+        game.stop()
+
+        //third test
+        game.start()
+        repeat(3) { game.goal(Game.Team.RED) }
+        repeat(3) { game.goal(Game.Team.BLUE) }
+        assertEquals("RED 3:3 BLUE", game.getScore())
+        game.stop()
+    }
+}
+{% endhighlight %}
 
 ## Zasady
 JUnit umożliwia dodawanie zachowania do każdego testu za pomocą adnotacji `@Rule` oraz tworzenie nowych zasad. Aby stworzyć własną zasadę należy w klasie zasady implementować interfejs `TestRule`. 
 
-//TODO przyklad z tworzeniem i uzyciem wlasnej zasady
+{% highlight kotlin %}
+class RuleTest {
+
+    @Rule @JvmField
+    val rule = PrintTestRule() //this rule print message before and after every test
+
+    val game = Game()
+
+    @Test
+    fun addPlayersWithSameNameToTheSameTeam() {
+        game.addPlayer(Game.Team.RED, "Johnnie")
+        game.addPlayer(Game.Team.RED, "William")
+        game.addPlayer(Game.Team.RED, "Jack")
+        game.addPlayer(Game.Team.RED, "William")
+        assertEquals(3, game.getRedTeam().size)
+    }
+
+    @Test
+    fun addPlayersWithSameNameToTheAnotherTeam() {
+        game.addPlayer(Game.Team.RED, "Johnnie")
+        game.addPlayer(Game.Team.RED, "William")
+        game.addPlayer(Game.Team.BLUE, "Jack")
+        game.addPlayer(Game.Team.BLUE, "William")
+        assertEquals(1, game.getBlueTeam().size)
+    }
+}
+
+class PrintTestRule : TestRule {
+
+    private lateinit var base: Statement
+    private lateinit var description: Description
+
+    override fun apply(base: Statement, description: Description): Statement {
+        this.base = base
+        this.description = description
+        return PrintTestStatement(base)
+    }
+
+    class PrintTestStatement(private val base: Statement) : Statement() {
+        override fun evaluate() {
+            println("Log before test action")
+            base.evaluate()
+            println("Log after testaction")
+        }
+    }
+}
+{% endhighlight %}
 
 `AndroidX Test` zawiera zestaw gotowych zasad dla JUnit, które zwiększają elastyczność, redukują powtarzający się kod oraz wspomagają testowanie komponentów Android. Wykorzystywane są przede wszystkim testach UI przy użyciu `Espresso`. `ActivityTestRule` dostarcza do klasy testowej żądanej Aktywności (`Activity`), która jest dostępna w całym cyklu życia klasy testowej, `ServiceTestRule` dostarcza Usługę (`Service`) natomiast `IntentsTestRule` dostarcza Intencję (`Intent`). 
 
-## Filtry
-`AndroidJUnitRunner` umożliwia stosowanie adnotacji w celach czysto informacyjnych. Adnotacja `@RequiresDevice` mówi, że test powinien zostać przeprowadzony tylko na urządzeniu fizycznym, `@SdkSupress` określa minimalne API natomiast `@SmallTest`, `@MediumTest` i `@LargeTest` mówią o wielkości testu co przekłada się na czas jego wykonania.
+//TODO maybe
 
-//TODO example
+## Filtry
+`AndroidJUnitRunner` umożliwia stosowanie adnotacji dla testów instrumentalnych w celach informacyjnych. Adnotacja `@RequiresDevice` mówi, że test powinien zostać przeprowadzony tylko na urządzeniu fizycznym, `@SdkSupress` określa minimalne API natomiast `@SmallTest`, `@MediumTest` i `@LargeTest` informują o wielkości testu co przekłada się na czas jego wykonania.