Can anyone direct me to a nice resource (which may...

# android

[Wahib]

Can anyone direct me to a nice resource (which may have helped you) for learning to write Unit Tests using http://mockk.io with MVVM, LiveData, Coroutines and of course Kotlin in an Android project? 🙏

[ghedeon]

#mockk ?

[rkeazor]

Learn to write unit tests first. Than you can use any isolation library you want. They all do almost the same thing.

[ghedeon]

or, save yourself time and accept that TDD is like 100% coverage: sounds good, doesn't work. (ATDD or contract development on the other side is very practical)

[rkeazor]

Tdd works well, and helps you write efficient code. Because the wacker your code is the harder it will be to get that green light lol

[ghedeon]

we're in the slack of the practical language after all) Does it sound familiar to you:
1) All or nothing, I'm doing TDD!
2) I wrote a failing test, defined some interfaces, working my way with the implementation
3) 1hr later: oh wait, I change my mind, now my function accepts a callback. Let me rewrite all my tests.
4) 2hr later. Oh wait, my class got bigger, let me split it in two. Shit.. I need to split my tests now... Hm.. I know I should, but maybe, just maybe, I'll change my mind about the class 5 min later, I'll need to bring my tests back? Ok, nobody will notice, if I forget about the test file until my implementation is 100% stable.
5) Congratulations, you're done with TDD. It was a short journey.
How practical is that? No, srsly, how many teams have you seen that follow pure TDD? In 7 years I didn't see one. But I've seen a lot of TDD coaches, lol)

The fundamental problem is the mistaken idea, that you start with some nice interface or well defined expected behavior in mind, and you can write a test for it. But there is no such interface. You'll change it 100 times.

On a higher level tho, in acceptance tests, for example, or between App and Backend, there are well-defined scenarios and contracts. You write a test for the contract (let say the Rest Api is not ready, but you know the expected schema, so you don't wait for them). The contract is invariant, it stays the same. So you have something stable that you can work with, without constantly rewriting it from scratch.
I guess it's called ATDD and unlike TDD it's realistic. Writing acceptance tests for bugs, for example. It's awesome! You write an Espresso scenario that leads to a bug, It's red, you make it green, the scenario didn't change a bit during your work!

[rkeazor]

@ghedeon Sorry for responding to this thread late. The fact that you keep having to rewrite your code isn't a fault created by TDD, it is a fault created by not planning out a approach what your going to code properly... The good thing about TDD, is that it makes your think of your approach to solving a problem up front. Rather than as you go along. Not only that, it forces you to make better code decision. For instance you end up asking yourself "do I inject a dependency , or do I just create one on the fly ?" Well because your writing tests first you know its easier to mock dependencies that are injected rather than created. Acceptance test are another type of test, but it doesn't make Unit Test or TDD less useful ...

[ghedeon]

I mean.. do I even need tests if I'm that good?) If I plan everything ahead, my approach is bright from the first go, I take only good code decisions and then TDD works? Got it simple smile.
https://twitter.com/dan_abramov/status/1086418722124906497