https://kotlinlang.org logo
Join Slack
Powered by
you never need to mock that class as it's stateles...
# android
j
you never need to mock that class as it's stateless and contains only pure functions
➕ 6
a
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
Because you're trying to run it on the JVM where the implementation does not exist (as it's an Android API)
t
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
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
Pass Base64 implementation abstraction as argument or just use own Base64 implementation that available without Android Framework
or test it in instrumentation tests
a
like this fun String.encrypt(myBase64:Base64)?
g
yes
j
You're relying on Android's implementation, so you really should test it on Android.
👍 3
a
Thus instrumentation testing instead
j
Or, also, just implement base 64 encode/decode yourself since it's not too complicated
a
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
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
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
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
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
Not sure about AS coverage tool, because in this case you have 2 different reports one from unit, one from instrumentation
a
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
Intrumentation tests most probably slower than robolectric
a
Of course but adding in robolectric test when doing TDD really slows things down.
g
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
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
@rkeazor Do you happen to have a good example of that?
173 Views
Open in Slack
PreviousNext
Powered by