https://kotlinlang.org logo
#android
Title
# android
j

jw

04/10/2019, 2:25 AM
you never need to mock that class as it's stateless and contains only pure functions
6
a

Adam Kirk

04/10/2019, 2:27 AM
If I dont need to mock it? then why does it error with it saying its not mocked?
Method decode in android.util.Base64 not mocked
j

jw

04/10/2019, 2:29 AM
Because you're trying to run it on the JVM where the implementation does not exist (as it's an Android API)
t

tngcanh07

04/10/2019, 2:30 AM
as I know, android.util.Base64 is belong to android framework, you cannot run on JVM environment
i’m not sure if it’s a good solution. in my case, I have to create another android.util.Base64 in my
test
folder.
a

Adam Kirk

04/10/2019, 2:33 AM
Ok this makes sense, how do I go about testing this function? fun String.encrypt(): String? { try { val secretKey = SecretKeySpec(Base64.decode(Key.toByteArray(Charset.forName(“UTF-8”)), Base64.NO_WRAP), “AES”) val iv = IvParameterSpec(Base64.decode(IV, Base64.NO_WRAP)) val cipher = Cipher.getInstance(AlGORYTHM) cipher.init(Cipher.ENCRYPT_MODE, secretKey, iv) return String(Base64.encode(cipher.doFinal(this.toByteArray(Charset.forName(“UTF-8”))), Base64.NO_WRAP)) } catch (e: Exception) { e.printStackTrace() } return null }
g

gildor

04/10/2019, 2:34 AM
Pass Base64 implementation abstraction as argument or just use own Base64 implementation that available without Android Framework
or test it in instrumentation tests
a

Adam Kirk

04/10/2019, 2:35 AM
like this fun String.encrypt(myBase64:Base64)?
g

gildor

04/10/2019, 2:35 AM
yes
j

jw

04/10/2019, 2:36 AM
You're relying on Android's implementation, so you really should test it on Android.
👍 3
a

Adam Kirk

04/10/2019, 2:36 AM
Thus instrumentation testing instead
j

jw

04/10/2019, 2:37 AM
Or, also, just implement base 64 encode/decode yourself since it's not too complicated
a

Adam Kirk

04/10/2019, 2:37 AM
lol not complicated to one is well complicated to another ha 🙂
still a noob to all of this.
That being said (the advice is hugely appreciated)
maybe someone could advise if I where to move it to the instrumentation test how do I get android studio to see the coverage, I know that coverage is not all that important but still learning and figure there must be a way?
Well instrumentation test was easy lol 🙂 and works so thank you again.
g

gildor

04/10/2019, 2:58 AM
lol not complicated to one is well complicated to another ha
You can just copy implementation from AOSP, Apache 2.0, so it’s legal also didn’t change for 9 years
🙂 1
a

Adam Kirk

04/10/2019, 3:01 AM
But truly overkill as Jake had indicated best to just move the test to instrumentation test. Sucks cause it pulls my code coverage down (but If I where to implement from ASOP then i would have to write test for that (seems silly). If there is a way to tell the code coverage to ignore or include stuff that’s tested by the instrumentation test that would be ideal.
g

gildor

04/10/2019, 3:04 AM
Depends on what is “overkill” for you. For me overkill is to use a couple Util methods from Framework and be forced to run them on a real device
👍 3
a

Adam Kirk

04/10/2019, 3:10 AM
I have that it doesnt seem to factor in the built in android studio code coverage tool
This one. I did however figure out how to ignore a file.
g

gildor

04/10/2019, 3:11 AM
Not sure about AS coverage tool, because in this case you have 2 different reports one from unit, one from instrumentation
a

Adam Kirk

04/10/2019, 3:12 AM
right.
yeah it seems that it only includes the ones from unit
I could also have used robolectric but i find its very slow
g

gildor

04/10/2019, 3:47 AM
Intrumentation tests most probably slower than robolectric
a

Adam Kirk

04/10/2019, 3:48 AM
Of course but adding in robolectric test when doing TDD really slows things down.
g

ghedeon

04/10/2019, 8:57 AM
as Jake had indicated best to just move the test to instrumentation test.
Best is to write an abstraction (wrapper) if you don't want to mess with copy-pasting implementation. Instrumentation is least favorite out of these 3 options.
r

rkeazor

04/11/2019, 10:39 AM
Roboelectric might be slow, but its probably better than manually mocking out all those Android stubs 😅. Your app should be architected in a way ,that separates all the business logic from the android specific code.. than you should just be unit testing your business logic and instrumentation testing your UI stuff
🤣 1
a

Adam Kirk

04/12/2019, 12:50 AM
@rkeazor Do you happen to have a good example of that?
133 Views