Android Programjaim

Androidfejlesztes

Teszteles androidon #4 - Instrumentation tests

2016. augusztus 10. 13:28 - lacas82

Lassuk mit ir errol a Vogella: Az Android Testing API lehetoseget ad, hookokra az android komponensekhez es eletciklushoz. Es persze a felhasznaloi interakciokhoz.

Azaz pl van egy Activityd, azon egy gomb, instrumentation-on keresztul lehetoseged van ezeket kodbol tesztelni. PL egy gombnyomast tudsz szimulalni.

Az instument. tesztek azok olyan unit tesztek, amik a mobil eszkozon vagy az emulatoron futnak nyilvan nem a JVM-en. Mig ugye a local unit teszt az a JVM-en fut.

Mockito egy mocking keretrendszer, amivel tudjuk mokkolni azokat az android rendszer reszeket amik nem szuksegesek a tesztunkhoz.

Az instrumentation alapu teszt tehat egy olyan osztaly, ami megengedi, hogy pl key eventeket kuldjunk vagy touch eventeket egy bizonyos cuccnak at. Pl. egy Viewnak ugye.

Vagy pl el tud inditani egy masik activity-t teszt celjabol, etc.

Az alap test runner ez esetben a:

InstrumentationTestRunner

es a helyuk pedig:

app/src/androidTest/java

gradle-be mik kellenek ehhez:

defaultConfig {
       ..... more stuff
        testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
    }

dependencies {
    // Unit testing dependencies
    androidTestCompile 'junit:junit:4.12'
    // Set this dependency if you want to use the Hamcrest matcher library
    androidTestCompile 'org.hamcrest:hamcrest-library:1.3'
    // more stuff, e.g., Mockito
}

Majd a tesztunket annotalni kell ezzel:

@RunWith(AndroidJUnit4.class)

ami a JUnit4 leszarmazottja.

A tesztek futtatasa parancssorbol:

gradlew connectedCheck

AS-bol, pedig Run a classon.

Teszt riportok helye:
app/build/reports/androidTests/connected/

Teszteles androidon #3

2016. augusztus 10. 10:28 - lacas82

OK, lathattunk peldat az elozoekben unit tesztre, de ez azert nem ilyen egyszeru, hosszu oldalak vannak megtomve a tesztelesekkel, es mar van eleg sok tesztelesi framework is mobilra.

Alapjaban veve ezeken fogunk atmenni, persze csak egyszeruen, erthetoen, nem megyunk bele melyebben a dolgokba.:)

Akit erdekel, par link a mobil es azon belul is androidos tesztekrol:

http://www.vogella.com/tutorials/AndroidTesting/article.html

https://github.com/googlesamples/android-testing - Android testing examples from Google]

https://github.com/googlesamples/android-testing-templates - Android testing template project from Google

http://tools.android.com/tech-docs/unit-testing-support - Unit test support description from Google

http://www.vogella.com/tutorials/Robolectric/article.html - Using Robolectric for Android unit testing on the JVM

http://www.vogella.com/tutorials/AndroidTestingEspresso/article.html - Android user interface testing with Espresso

http://blog.sqisland.com/2015/12/mock-application-in-espresso.html Chiu-Ki Chan about Mock Application in Espresso for Dependency Injection

https://artemzin.com/blog/how-to-mock-dependencies-in-unit-integration-and-functional-tests-dagger-robolectric-instrumentation/ Artem Zinnatullin blog post on How to mock dependencies in Unit, Integration and Functional tests; Dagger, Robolectric and Instrumentation

 

http://www.tesztelesagyakorlatban.hu/index.php

https://io2015codelabs.appspot.com/codelabs/android-studio-testing

Mint lathato azert nem egyszeru, es ez meg csak nem is az elmeleti resze. Aki azzal kivan foglalkozni, az talal meg sok-sok vicces linket, es elmeleti forrast, de mi most erre koncentralunk.

Teszteles androidon #2

2016. augusztus 10. 09:16 - lacas82

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

  • app/src/main/java

    a normal forraskodod ugye itt helyezkedik el

  • app/src/test/java 

    unit tesztek, amik a jvm-en futnak

  • app/src/androidTest/java 

    android tesztek, amik az eszkozon futnak

"error duplicate files in path" hiba javitasa:

""error duplicate files in path. Path in archive: LICENSE.txt"

gradle-be bemasoljuk ezt:

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


dependencies-be pedig:

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

 

Teszt riportok helye:

app/build/reports/tests/debug/

Aktivaljuk a default visszateresi erteket a mocked android.jar-nal:

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

 Teszt konyvtarak keszitese:

http://www.vogella.com/tutorials/AndroidTesting/article.html#androidtesting_creatingtestfolders

 Nezzunk egy egyszeru unittest-et androidon:

@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

Most nezzunk egy masik peldat:

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!



Címkék: teszt junit unittest

Teszteles androidon #1

2016. augusztus 07. 18:42 - lacas82

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..

 

Címkék: teszt junit unittest

RxAndroid - 4. resz - RxBinding

2016. július 06. 14:23 - lacas82

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