empty robolectric post added

Author: maciej-nowak

_drafts/2019-01-21-mockito.md

@@ -1,19 +1,19 @@
 ---
 layout: post
 title: "Mockito"
-date:  2019-01-21
+date: 2019-01-21
 categories: ["Testowanie"]
 image: testing/mockito
 github: testing/tree/master/mockito
 description: "Mockito"
-keywords: "testowanie, testing, testy, jednostkowe, automatyczne, lokalne, instrumentalne, dubler, zaślepka, atrapa, unit test, mock, spy, stub, junit, verify, when, thenreturn, answer, robolectric, mockito, android, programowanie, programming"
+keywords: "testowanie, testing, testy, jednostkowe, automatyczne, lokalne, dubler, zaślepka, atrapa, unit test, mock, spy, stub, junit, verify, when, thenreturn, answer, mockito, powermock, mockk, robolectric, android, programowanie, programming"
 ---
 
 ## Dublerzy
 Testy jednostkowe rzadko kiedy dotyczą jednostki testowej wolnej od zależności innych obiektów co w konsekwencji prowadzi do definicji problemu tworzenia niezależnych testów na których rezultat nie ma wpływu żadna zależność testowanej jednostki. Wymaganą prawdziwą zależność można czasami dostarczyć ręcznie jednakże jest to kosztowne, obarczone marginesem błędu oraz często niewykonalne (szczególnie w przypadku testów instrumentalnych). Alternatywą dla tworzenia prawdziwych zależności jest dostarczanie `dublerów` (`double test`), które można sklasyfikować ze względu na przeznaczenie. Jedna z wielu definicji wyróżnia m.in. następujące obiekty: `dummy`, `fake`, `stub` i `mock`. `Dummy` jest przekazywany w celu spełnienia założeń sygnatury jednak jego metody nie są wywoływane. `Fake` posiada uproszczoną działającą implementacje spełniającą założenia interakcji. `Stub` dostarcza minimalną implementacją zależności, która pomija proces obliczeniowy i bezpośrednio zwraca zdefiniowany rezultat w taki sposób, aby test wykonał się pozytywnie. Natomiast `mock` to naiwna implementacja zależności, która bierze udział w procesie testowania i rejestruje nawiązane z nią interakcje, przeznaczona do badania zachowania. Mnogość definicji podziału dublerów oraz wynikające z tego różnice są powodem wielu niejasności, a sama terminologia jest mało istotna w procesie tworzenia zastępników. Pozwala on jednak zrozumieć co dokładnie i w jaki sposób ma zostać przetestowane. `Mockito` jest frameworkiem wspomagającym pisanie testów jednostkowych poprzez dostarczanie dublerów, które dzieli na zwyczajne `Mock` oraz częściowe `Spy`.
 
 >**Przykład**  
->Na podstawie poniższych klas Manager oraz Data zostaną przedstawione cechy i właściwości zarządzania naiwnymi implementacjami w Mockito.
+>Na podstawie poniższych klas `Manager` oraz `Data` zostaną przedstawione cechy i właściwości zarządzania naiwnymi implementacjami w Mockito.
 
 {% highlight kotlin %}
 class Manager(val data: Data) {
@@ -341,4 +341,4 @@ class PowerMockTest {
 }
 {% endhighlight %}
 
-Jako alternatywę dla Mockito i PowerMock w `Kotlin` warto rozważyć bibliotekę `Mockk`, która rozwiązuje problemy występujące w Mockito i wspiera natywne cechy Kotlin takie jak np.: rozszerzenia.
+Jako alternatywę dla Mockito i PowerMock w `Kotlin` warto rozważyć bibliotekę `Mockk`, która rozwiązuje problemy występujące w Mockito i wspiera natywne cechy Kotlin takie jak np.: rozszerzenia. Framework `Robolectric` umożliwi natomiast przeprowadzanie w łatwy sposób instrumentalnych testów jednostkowych.

_drafts/2019-01-28-robolectric.md

@@ -0,0 +1,10 @@
+---
+layout: post
+title: "Robolectric"
+date: 2019-01-28
+categories: ["Testowanie"]
+image: testing/robolectric
+github: testing/tree/master/robolectric
+description: "Robolectric"
+keywords: "testowanie, testing, testy, jednostkowe, automatyczne, instrumentalne, zaślepka, atrapa, unit test, mock, stub, robolectric, android, programowanie, programming"
+---