hello, MyWay!

how can I help you today?

hello Mark!

From what I've understand there are two types of test: one running on jvm (e.g. junit) and one running on android framework (e.g. espresso), is this right? My first question is... what should I test? As it's me writing the test, probably I'd write only test which I already know will be passed (or I'd have already fixed the bug!). So what's the point of writing these kind of tests? Any tool to "random" stress test the app?

"is this right?" -- mostly. JUnit4 is used for both unit testing (on the JVM) and instrumentation testing (with or without Espresso orUiAutomator)

"what should I test?" -- your code! :-)

"So what's the point of writing these kind of tests?" -- ideally, you aim for 100% code coverage

that will ensure that you are testing all scenarios, not just the few that you know will work

and, it will help you if you make changes to the code that break the app

so if there is a click on a button, I should test that the button is in the right state

"Any tool to random stress test the app?" -- there is the Test Monkey

I don't know that a button would have a state

but, presumably, when the user clicks the button, something is supposed to happen

yes

you test to confirm that the "something" actually happened

if I remember (maybe from your book), test monkey is a bit "limited"

it is random GUI input

it clicks on widgets and taps keys (e.g., BACK, HOME)

your job is to survive the monkey

i.e., not crash, regardless of what the monkey throws at you

eheh

yes, this seems good to me, because it could do something you didn't prevent

while when you write test, you're auto-fixing your code, in a sense

well, yes and no

that's where coverage analysis comes into play

for any app of reasonable complexity, you will not be able to determine, by just looking at it, whether a test is guaranteed to run successfully

you won't even necessarily know all the portions of the app that test touches

so, you use coverage tools to try to test everything

or as close to "everything" as you are in position to get

this will include things like exception handlers and other failure scenarios

I see

about UI test, I'd like to add some: e.g. when the user swipe (or tap on a tab), I'd like to check that the viewpager switch to the right page, that the tab corrisponds and so on... I've seen many examples, but all very simple. Where can I find more info about testing, or more complex examples? This is what I'm trying to do: http://stackoverflow.com/questions/38708462/and...

I have several chapters related to testing, but they would all qualify as "simple"

it is possible that a dedicated book on Android testing, particularly Espresso, might get into details of the level that you seek

I think my problem is at "matching" the ui component, but I'm not sure

you can run tests in the debugger

beyond that, I can't really help you, as I have no idea what your code is that you are testing, other than the limited information in your SO question

I did a lot of tests, everything works, but when it come to that line (onView() or onData()) it hangs, or timeout, (or fails)

but if I write onView(withText("Test 1")), shouldn't it match everything which has Test 1 inside?

onView() will probably choose the first one returned by the matcher

I don't think the ViewInteraction created by onView() works over N views

in my case there is one, I want to match it, but it seems it does not get matched

I don't want the solution, but how should I proceed?

perhaps there is something odd with TabLayout that does not work well with Espresso

ah

while many widgets will be testable "out of the box", not all will

that's why espresso-contrib has dedicated classes to help with RecyclerView, for example

it's possible that TabLayout would need the same treatment

nice, I'll read more about Espresso in a specific book, as you said

you might also consider creating a sample app that reproduces your problem in testing TabLayout

then, use that as the basis of a fresh SO question, focusing on how to test TabLayout with Espresso

and, depending on what you get from that, perhaps file an issue on the issue tracker, with that sample project

let me take a question from Ivano, and I will be back with you shortly

yes, thank you

Ivano: your turn! do you have a question?

Ivano: do you have a question?

Ivano: if you have a question, chime in

MyWay: back to you! do you have another question?

I Mark, I truly apoligize, but I am at 3PM, and my boss asked me a question asa icome

into the chat

is undependent by me

I have two things to communicate you

first is a remark over pag 994 7.5 edition

but in the exhibit there is any debug{testCoverageEnabled = true}

correct

sure there is

can be confusing, also in the git file did not see

it is at the bottom of the code listing on page 994

you are right

it is also at the bottom of the file in the git repo

OMG, maybe was 7.4 edition

anyway I am clamorously wrong

that's possible -- there may have been a bug that was fixed

the second thing is over debugging...

I am really curios to understand better the debug stacktrace, but cannot find nothing on the internet that explains what are the shadow$ klass, etc

do you know where I can find more instruction to become a professional "breakpointer"?

um, not really

:(

if by "shadow$ klass", you mean classes of the form MainActivity$1, those are anonymous inner classes

??? made by the system reflection?

e.g., button.setOnClickListener(new View.OnClickListener() { public void onClick(View v) { // do something }}

(though I missed the ); at the end of that code snippet)

nobody is perfect

mmh not sure we are speaking about the same thing

if you can post a stack trace that shows what you are referring to, that might help

sometimes for instance i found shadow$ klass = java.lang.String

this is great, I will come back soon to you, thank you mark, for your meta suggestions, these questions would be downvoted in SO

I do not recognize that, so I cannot tell you what it might refer to, sorry

OK

I will be more precise next week

thanks

let me take another question from MyWay, and I will be back with you shortly

MyWay: back to you! do you have another question?

I'd like to add some new feature to my app, to do it I'd like to use a remote database to store some info. My question is: own server or already existent solution (e.g. google firebase)? My concerns are mainly about security. E.g. I want to save each user position (so database + rest api on the server, I think). I've also found this library, which seems interesting: https://github.com/jeffknupp/sandman2

there is no universal answer, but what do you think about it?

personally, I am enough of a "control freak" that I would use my own server

plenty of people use hosted BaaS (backend as a service) solutions like Firebase, though

middle ground would be to host something like Parse's open source server yourself

https://github.com/ParsePlatform this one?

I believe that is it

I'll read about it, thanks

a last thing... what do you think about the new google android developer certification? Have you done it already? :P

(????)

I have not been certified, as I have not had a need to

I am somewhat surprised that Google elected to get into the developer certification space

yes

until there is demand from employers for candidates to get certified, I would not worry about it too much

that's all for me, thank you very much as always, Mark

you are very welcome

have a good day!

bye all

Ivano: we are referring to https://developers.google.com/training/certific...

Google announced it at the 2016 I|O conference

saw is the nanodegree, I did it already the old version

Ivano: back to you! do you have another question?

well Mark do you know, I do not want really to ask too much every time, but you know the firebase/ server makes me curios over...

the fact why android devs prefers LAMP, over the great Jersey Java framework

the only explanation i can give to my self is that JAVA cost more to host

do you have any remark on that?

I cannot speak regarding Jersey, as I have not used it

ok, looks cool to me.

in general, different server stacks have had prominence over the years

WAR-based Java Web app servers were the first big one, in the post-CGI era

then, Ruby, mostly via Rails

now, NodeJS

learning, learning, learning

in many cases, the people driving the choices for the server are not the Android developers, but the Web app developers

since the same server gets used for both

I see, good point

OK thanks

an Android developer might want Java on the server, for the same language on the client and the server, much as Web developers are interested in NodeJS, for the same language on the client and the server, but for a different client (Web vs. Android)

makes sense. will see is a javascript vs java war

for sure learning is always essential, i cannot dare to think i should learn even C, and C++ if want to do VR Android

that's a wrap for today's chat

the transcript will be posted to https://commonsware.com/office-hours/ shortly

have a nice US day, thanks

the next chat is Tuesday at 9am US Eastern

have a pleasant day/night/whatever! :-)