I just ran across this doc which gives official an...

# compose

[jim]

I just ran across this doc which gives official androidx guidance around mocking: https://android.googlesource.com/platform/frameworks/support/+/androidx-main/docs/do_not_mock.md

It nominally applies to the androidx codebase, but I'd encourage external developers to adopt similar thinking, as it really cleans up both your APIs and ensures you're testing the right contracts.

[Bryan Herbst]

Thanks for the link! We’ve been pushing that direction as well and that’s a great resource

[Joost Klitsie]

Good link indeed! Do you have then also examples of how to test without mocks? I see the examples of what not to do, but then I wonder what should I do :)

[jim]

Either use real/existing data structures and implementations, or create a class which implements the relevant interfaces. If it's not easy and you find yourself reaching for a mocking framework, its a strong indication that your API is not adequately generalized/designed.

[Joost Klitsie]

I would try not to use real implementations other than the SUT, because it will not be Unit tests anymore if you test multiple classes at the same time. It sounds to me like test implementations for interfaces is the way to go, luckily we try to use interfaces all over the place 🙂 but yeah I wasn't aware mocking is frowned upon, good to know! I guess it should speed up testing as well, Mockk is notoriously slow in creating mocks for example, mockito I haven't tried out yet in kotlin but I can imagine test speed going up there as well without mocking

[jim]

Your code is always testing multiple classes at the same time, unless you literally avoid all JVM classes including List, Integer, String, etc. Heck, when testing with a mocking framework, you are implicitly testing the mocking framework classes. When a test is taking dependencies, it's all just a matter of degree. Unit tests should be as small as possible, but no smaller than necessary to test the desired functionality.