Android Programjaim

Android fejlesztes, java, kotlin, web.. miegymas:)

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

RxAndroid - 3. resz - Retrolambda

2016. július 06. 11:56 - lacas82

Ebben a reszben a lambda-krol lesz szo, azon belul is a retrolambdarol.
Eloszor is miert jo nekunk az RxAndroid, es a lambdak?

Lecsokkenti a kod nagysagat, illetve elkerulheto vele a callback hell.

OK, be kell allitanunk nehany dolgot az android projectunkbe, hogy hasznalni tudjuk a retrolambdat, nezzuk mik ezek.

A root build.gradle-be a dependencybe ezt bemasolni:

classpath 'me.tatarka:gradle-retrolambda:3.1.0'

Ez a library atforditja a lamdba kodot valami olyasmive, amit az android studio is erteni fog.

az app gradle elso soraba pedig ezt:

apply plugin: 'me.tatarka.retrolambda'

majd ezt

android {
...
compileOptions {
sourceCompatibility JavaVersion.VERSION_1_8
targetCompatibility JavaVersion.VERSION_1_8
}
}

vegul a retrolambdat

retrolambda {
jdk System.getenv('JAVA8_HOME')
oldJdk System.getenv('JAVA7_HOME')
}

Elvileg ha minden flottul ment es run-oljuk a cuccot pl device-en,
akkor megy, ha nem, akkor kiirja valoszinu ezt:

 

Error:Execution failed for task ‘:app:compileDebugJava’.
> When running gradle with java 6 or 7, you must set the path to jdk8,
either with property retrolambda.jdk or environment variable JAVA8_HOME

Valszeg java7 van beallitva a settings-ben, ezert egyszeru a megoldasa:

File -> Project Structure -> SDK Location -> JDK Location

Itt a JDK7 utvonalat atrakjuk a JDK8 utvonalara. Ezutan mukodni fog.

Ha minden jol ment, akkor bizonyos kodreszleteink elszurkulnek, es kiir ra ilyesmiket:

Anonymous new Action1<String>() can be replaced with lambda...

Alt+Enterre pedig ki is csereli a kodot, azaz egyszerusiti.

Nezzuk milyen volt:

public void listTest() {

String[] manyWords = new String[]{"a", "b", "c"};

Observable<String> oneByOneObservable = Observable.from(manyWords);

Action1<String> action = new Action1<String>() {
@Override
public void call(String s) {
Toast.makeText(mAct, s, Toast.LENGTH_LONG).show();
}
};

Func1<String, String> map = new Func1<String, String>() {
@Override
public String call(String s) {
return s.toUpperCase() + s.toLowerCase() + s.toUpperCase();
}
};

oneByOneObservable
.observeOn(AndroidSchedulers.mainThread())
.map(map)
.subscribe(action);
}

Es milyen lett:

 

public void listTest() {

String[] manyWords = new String[]{"a", "b", "c"};

Observable<String> oneByOneObservable = Observable.from(manyWords);

Action1<String> action = s -> Toast.makeText(mAct, s, Toast.LENGTH_LONG).show();

Func1<String, String> map = s -> s.toUpperCase() + s.toLowerCase() + s.toUpperCase();

oneByOneObservable
.observeOn(AndroidSchedulers.mainThread())
.map(map)
.subscribe(action);
}

 Nezzunk egy masik peldat:

Func1<String, String> toUpperCaseMap = new Func1<String, String>() {
@Override
public String call(String s) {
return s.toUpperCase();
}
};

Ezt eloszor egyszerusiteni tudjuk lambdaval:

Func1<String, String> toUpperCaseMap = s -> s.toUpperCase();

majd:

Func1<String, String> toUpperCaseMap = String::toUpperCase;

RxAndroid - 2. resz

2016. július 04. 12:47 - lacas82

Action1<String> textViewOnNextAction = new Action1<String>() {
@Override
public void call(String s) {
txtPart1.setText(s);
}
};


Kezdjunk is bele! Az Action1 tulajdonkeppen egy hivas/tortenes,
ami nyilvan ismeros lehet ha irtunk mar interface-t generikusan. Ez itt 
egy hivas, ami visszaad egy Stringet esetunkben, de persze a String barmi mar lehet. 


Eddig ugye ezt hasznaltuk arra, hogy a textView-be visszakapjuk a "Hello World"-ot.
De mi van, ha nem a Hello World-ot akarjuk, hanem nagybetukkel a HELLO WORLD-ot?

Akkor letre kell hoznunk egy Func1 nevu metodust:

Func1<String, String> toUpperCaseMap = new Func1<String, String>(){
@Override
public String call(String s) {
return s.toUpperCase();
}
};

Ez ugye nagybetuve alakitja siman, ez egy map lesz. A ket String az input, outputot szimbolizalja.

Nezzuk egyszerubben az Observables-unket:

Observable<String> singleObservable = Observable.just(“Hello, World!”);


Lehetosegunk van a "just" statikus metodust meghivni, ami siman egy shortcut a "Hello World"-re.


Majd osszedrotozzuk:

singleObservable.observeOn(AndroidSchedulers.mainThread())
.map(toUpperCaseMap)
.subscribe(textViewOnNextAction);

 

Az uj dolog itt a map operator! Mi ez? Mielott atdobnank az eredmenyt a subscribernek, meg elvegezzuk rajta a

szukseges modositast, azaz nagybetusse alakitjuk. Majd ezt adjuk vissza. Nagyon sok operator erheto el, ezt egyelore ne is ragozzuk.


Eddig azt lattuk, hogyan lehet egy elemet atadni, de akarmennyit lehet, lassunk peldat List-ekre is mondjuk.

Action1<String> toastOnNextAction = new Action1<String>() {
@Override
public void call(String s) {
Toast.makeText(context, s, Toast.LENGTH_SHORT).show();
}
};

Eddig semmi uj dolog...
Observable<String> oneByOneObservable = Observable.from(manyWords);


vagy

Observable.just(manyWordList);

flatMap

Func1<List<String>, Observable<String>> getUrls = new Func1<List<String>, Observable<String>>() {
@Override
public Observable<String> call (List<String> strings) {
return Observable.from(strings);
}
};

Func2<String, String, String> mergeRoutine = new Func2<String, String, String>() {
@Override
public String call (String s, String s1) {
return String.format(“%s %s”,s, s1);
}
};

Observable.just(manyWordList)
.observeOn(AndroidSchedulers.mainThread())
.flatMap(getUrls)
.reduce(mergeRoutine)
.subscribe(toastOnNextAction);


Teljes forraskod
Címkék: RxAndroid