What should I do when no one is available to help?

I empathize with this situation a lot: It's easy to fall into a situation like this which feels helpless, especially when you work in a small startup where very few (or even 0) people in the company have experience in the problem space you're working on.

There are many ways to get out of this situation (including a 🌶️🔥 one that I'll write up in a separate comment):

• Escalate - It looks like these unit tests tasks are important and have due dates. If the team has agreed upon this, they're responsible for providing you the support you need to deliver. If the due date is close and you haven't made enough progress, bring this up urgently with your manager and see if you can set up a 1-2 hour pair programming block where you two just go super deep on Mockk knowledge transfer. Make sure to ask follow-up questions so you are able to fully "download" your manager's expertise as we talk about in this video: How To Actually Learn Software Engineer Skills
• Ask questions online - I looked up Mockk, and it's a pretty major library with 5,000+ stars on GitHub. I'm sure it has a decently sized online community around it: If you aren't able to get a teammate to help you, you can turn to asking questions on StackOverflow and GitHub. For that, I recommend this video breaking down how to ask a good technical question: Bad Question vs. Good Question Example
• Descope - Not all unit tests are created equal: Some are harder to write than others. In particular, Android's notorious god object, the Context, is annoying to unit test with. If you aren't able to complete everything on-time, you can try applying the 80/20 rule to your proposed testing suite, doing the simple low-hanging fruit tests that also have high-impact while deprioritizing the gnarlier ones.
• Make your code more testable - Unit tests get really hard to write when logic is not properly decoupled, especially when it's tangled deeply into the view controllers (i.e. Activities and Fragments). If your code looks like this way, try to split it up more, particularly into utility functions where the input/output are very well-defined.

What If... You Just Don't Have Tests?

Unit tests make much more sense on back-end than front-end IMHO, and mobile is especially well-positioned to be less reliant on automated tests. This is why Instagram didn't have serious automated test coverage on mobile until it was well over 1 billion users. Here's the why behind all this:

• As mentioned in the earlier comment, mobile business logic can be very finicky to test. This is especially true on Android with mocking Context.
• Mobile UI is very annoying to get right due to the immense device variety. Android again is disadvantaged here due to its insanely large device pool.
• Mobile is the most "dogfood-able" product type. It's front-end, so it's friendly to users. Mobile is also naturally convenient, so it's very easy for employees to just pull out their phones and play around with the app whenever (especially if it's a consumer app). A very aggressive dogfooding program (employees got main branch deployed on their phones) was how Instagram caught the vast majority of its bugs up to 1 billion users.
• I have never met a mobile testing framework that just worked. Even with all the infrastructure across Espresso, JUnit, Roboelectric, and more, everything I have ever worked with had serious problems with environment setup and flakiness.
• At the end of the day, automated tests are a "1 step backwards, 2 steps forward" play. They usually require significant time investment upfront, and you are hoping that it saves time and product sentiment going forward by proactively catching regressions/bugs. The question is whether you are in position to cash in on the "2 steps" part on a reasonable time-scale: For example, if you take the time to add unit tests to a unimportant module that will never be touched, you will literally never get the benefit.

I don't know how things are going with the reliability of your product, what parts of it are breaking, and the collaborative health of your Android team, so this is a call you'll need to make at the end of the day. It's very possible that unit tests are 100% the right way to go, and it's also possible that you should be investing in other quality strategies like enhanced dogfooding, more thorough code review test plans, and increased alerting instead.

Lastly, another "nuclear" option is to use a different framework to write the tests. 5k GitHub stars is a lot, but I have seen frameworks with more. You can try working backwards from the documentation: Just go with whatever library has the best examples.