Nezzuk mandroidon a teszteket, tesztelesi elofeltetelek:
Eloszor is a strukturat:

android {
    packagingOptions {
    exclude 'LICENSE.txt'
    }
}

testCompile 'junit:junit:4.12'
testCompile 'org.hamcrest:hamcrest-library:1.3'


Futtatni a teszteket parancssorbol a 
gradlew test

-el tudjuk

Vagy Android Studio-ban kurzor a Test class-on, jobb klikk, es Run ...Test

android {
  // ...
  testOptions {
    unitTests.returnDefaultValues = true
  }
}

@Test
public void stringEmptyTest() {
   String email = "";
   assertEquals("Valid email " + email, EmailValidator.isValid(email), false);
}

@Test
public void stringNullTest() {
   String email = null;
   assertEquals("Valid email " + email, EmailValidator.isValid(email), false);
}

@Test
public void stringGoodTest1() {
   String email = "asd.co@arm.hu";
   assertEquals("Nem valid email " + email, EmailValidator.isValid(email), true);
}

@Test
public void stringGoodTest2() {
   String email = "asd@arm.hu";
   assertEquals("Nem valid email " + email, EmailValidator.isValid(email), true);
}

@Test
public void stringBadTest1() {
   String email = "aSd_arm.hu";
   assertEquals("Valid email " + email, EmailValidator.isValid(email), false);
}

..

stb

ha nyomunk AS-ben egy shift+f10-et (run), akkor azt az eredmenyt kapjuk pl hogy az 
osszes teszt OK-val lefutott

public class Calculator {

   public Calculator() { }

   public int plus(int a, int b) {
      return 0;
   }

   public int minus(int a, int b) {
      return 0;
   }
}

majd a teszt ra:

public class CalculatorTest {

   private Calculator mCalculator;

   @Before
   public void before() {
      mCalculator = new Calculator();
   }

   @Test
   public void testPlus() {
      assertEquals("Hiba", 7, mCalculator.plus(2, 5));
   }

   @Test
   public void testMinus() {
      assertEquals("Hiba", -3, mCalculator.minus(2, 5));
   }
...

Ha futtatjuk ezt kapjuk:

java.lang.AssertionError: Hiba 
Expected :-3
Actual   :0

java.lang.AssertionError: Hiba 
Expected :7
Actual   :0

Azaz, nyilvanvaloan a vart ertek 7 es -3 kene, hogy legyen. Mivel jelen esetben mindig 0-at vissza, 
igy ertheto miert, javitsuk ki az eredeti kodot.

public int plus(int a, int b) {
   return a + b;
}

public int minus(int a, int b) {
   return a - b;
}

majd futtassuk le ujra a tesztet:

es minden lefutott OK-val!

Ok ez meg nekem is kozepesen uj, ideje jobban megtanulni. Itt ugye nem a manualis tesztekrol lesz most szo. 

Javaban ugye unit teszt alatt a junit teszteket ertjuk, amivel metodusokat es osztalyokat tesztelhetunk. 

Altalaban minden osztalyra egy teszt osztaly keszul es minden metodusra egy teszt metodus. Az osztaly mukodese soran a mas osztalyokat mokoljuk. Easymock, mockito etc. 

Unit teszteket altalaban akkor kell irni, ha csapatban dolgozunk. 

Androidon a unit tesztek a jvm en futnak a gepen. Ezt local unit tesztnek is hivjak. Van meg az instrumentation unit teszt. Amikhez az android szukseges mar. 

 A local unit teszt nyilvan gyorsabb, mint a masik, ott ugyanis real eszkozon fut le a cucc. 

Unit tesztek jvm en es android runtime on is futtathatok. De persze van az Espresso, ami egy egyszeru user interface teszt framework. 

Ha az osztalyaid nem hivjak meg az android apit, akkor ezeket junit al tesztelheted. Hogyha fuggosegek vannak az android apival, akkor egy mocking framework kell, mint pl a Mockito.

Miket kell tesztelni egy android appon?

Az uzleti logikat:

maradek % pedig az UI tesztek

70-80% unit tesztek, hogy meggyozodjunk h. a kodbazisunk stabil

20-30% funkcionalis tesztek, h meggyozodjunk, h. az app tenyleg mukodik

TesztPiramisról

Az abran egy forditott mobil teszt piramis lathato.

A mobil applikációk tesztelése más szoftverekhez képest – mint pl. az asztali és a webes applikációk – olyan teljesen különböző tesztelési tevékenységeket igényel, mint a mozgás, a szenzorok, különböző eszközök és hálózatok. Rengeteg manuális tesztelés szükséges, hogy meggyőződjünk arról, egy mobil applikáció az elvárt módon működik a különböző használati esetek során.

Ennyit az elso reszrol, a masodik reszben bemutatom, hogy android eseteben android studional miket kell beallitani, hogy tesztelni tudjunk..

RxBinding, tulajdonkeppen annyi, hogy nem kell listenereket, es hosszu csunya kodokat irnunk, hanem minden View-re, stb-re tudunk aggatni egy Bind-ot, subscribe()-al

példák:

@Bind(R.id.button) Button button; //ez ugye a Butterknife-ot hasznalja

...

RxView.clicks(button).subscribe(aVoid -> onButtonClicked());

...

private void onButtonClicked() {
   Toast.makeText(this, "onButtonClicked", Toast.LENGTH_LONG).show();
}

Ha Butterknife-al egyutt hasznalnank, akkor kell a gradle-be egy ilyen is hozza:

packagingOptions {
exclude 'META-INF/services/javax.annotation.processing.Processor' // butterknife
}

Hogy ne zavarodjon be a build tole. Amugy meg van annotacios @OnClick Butterknife-ba, tehat ez vegulis felesleges, de van ilyen is. Hurra.

Masik pelda:

RxToolbar.navigationClicks(toolbar).subscribe(aVoid -> onToolbarNavigationClicked());


Azt kell latni, hogy ugyszolvan mindenhez van ilyen subscribe, az android osszes 
elemehez, es a design libraryhez is, meg a legujabb cuccokhoz is. 

Es egy kiforrottabb pelda:

usualApproachEditText.addTextChangedListener(new TextWatcher() {

  @Override
  public void beforeTextChanged(CharSequence s, int start, int    count, int after) {}

  @Override
  public void onTextChanged(CharSequence s, int start, int before, int count) {
    onNewTextChanged(s);
}

  @Override
  public void afterTextChanged(Editable s) {}
});

Ehelyett is tudunk RxBind-os megoldast:

RxTextView.textChanges(reactiveApproachEditText).subscribe(this::onNewTextChanged);

1 sor az egesz. Hat nem szebb es stilusosabb? Olvashatobb, rovidebb?
Kell ez nekunk? IGEEEEEN