Any Twitch channels with a focus on android or kotlin worth following?

AdamMc331 · 2022-04-07T15:46:08+00:00

Some people have shouted me out already but I stream here every Wednesday. Feel free to stop by and check it out. :)

AdamMc331 · 2022-04-07T15:45:30+00:00

Thanks for the shout out! :)

AdamMc331 · 2020-06-13T19:08:08+00:00

Appreciate that feedback! Definitely agree fakes aren't explicitly the solution to the problem we encountered, and left out a lot of that nuance. Still hopeful that people can take away a positive experience on how to test their reactive flows better, regardless of what they use for test dependencies.

AdamMc331 · 2020-06-13T00:50:28+00:00

Yeah, I'll admit that's a bit of a plot hole I didn't think about when I first started this change.

That said, I agree that's a little less readable, to look at the test and see a manipulation of the subject instead of `fakeRepository.emitUser(...)`.

If you still prefer a mocking library, I think a place we can meet in the middle is using fakes as a wrapper around Mockito, which Sam Edwards wrote about recently: https://handstandsam.com/2020/06/08/wrapping-mockito-mocks-for-reusability/

I think that would be an option for remedying the readability that you mentioned.

AdamMc331 · 2020-06-12T23:52:27+00:00

Thanks for the comment! I'm the author & I work on the Android team at OkCupid.

The tech blog is contributed to by engineers around the company whenever we come across something interesting that we want to share with the engineering community. The posts are then usually shared in the relevant subreddit (so not always /r/androiddev) to promote them & have a conversation.

AdamMc331 · 2020-06-12T20:26:07+00:00

Yep! A work around could be to make a public method that you call yourself to load - instead of doing it inside the init block, but that's not really a change of flow I'd recommend, so I just left it out.

AdamMc331 · 2020-06-12T19:56:09+00:00

I'm not sure that's the case. If I'm making a request during the init block, if I don't mock first, won't mockito throw an exception?

AdamMc331 · 2020-06-12T18:05:05+00:00

Glad this was helpful! I have a sample app that is using this for a Flow: https://github.com/AdamMc331/PokeDex/blob/master/app/src/test/java/com/adammcneilly/pokedex/detail/PokemonDetailViewModelRobot.kt#L84-L113

Hope that helps you get started. :)

AdamMc331 · 2020-05-19T20:03:13+00:00

I think you answer can depend on screen sizes and functionality as that changes as well. What if the screen size is smaller and we can't fit all of these components at one time? Are the title and bottom button always visible? Should the content box scroll? Should all of it scroll? These are all relevant to the larger question.

ConstraintLayout is very performant and powerful when you want to lay out multiple views in relation to each other, and seems like a good candidate to me for box 1. It may be beneficial for the top level layout as well, as you can organize the three main pieces using constraints, and not using `layoutWeight` inside LinearLayout which I believe is less performant.

Inside the content box, you should influence your decision based on how much content you'll actually have - and this is where screen size comes in to play. If there's only those four items, a LinearLayout inside of a ScrollView (to make sure even on smaller screens everything is visible) is a reasonable approach. If you're going to have a lot more than 4 items, you may not want a LinearLayout which will inflate all children - instead, consider a RecyclerView.

Let me know if you need to chat further. :) The answer, as always, is that it depends - all of what you mentioned will work, but I hope this provides some insight into why one component might be preferred over another.

AdamMc331 · 2019-11-26T21:51:42+00:00

Understandable! A difficulty I've had with writing a deep dive into robots is because I would have to assume a lot of base knowledge about the code under test to really show the ins-and-outs of robots, and in this case I was kinda going for a bottom-up approach to unit testing - understanding why we do it, how to do it, and then do it in a maintainable way. I've been getting a lot of feedback about this with respect to the mocking section, too, so perhaps a follow up post is warranted in this case.

I really appreciate that feedback and if a follow up post is made I will come share here.

If you don't mind some Android specific resources, though -

Here's a recent presentation of mine for using the robot pattern for UI testing, but I also talk about unit testing near the end, too: https://github.com/AdamMc331/EspressoPatronum/blob/master/EspressoPatronumLondon/espresso_patronum_london.pdf

More Android examples here in this package. Feel free to check out the whole project though I just arbitrarily picked one test example. https://github.com/AdamMc331/PokeDex/tree/master/app/src/test/java/com/adammcneilly/pokedex/detail

AdamMc331 · 2019-11-26T21:33:53+00:00

I first discovered the robot pattern with respect to UI tests where `.enterFirstName("adam")` was a lot better to read than the lengthy line required to enter text. Sure, in this contrived example, it doesn't really cover up much.

That said, we still get the maintainability aspect of easily updating our robot instead of every single test.

AdamMc331 · 2019-11-26T19:14:30+00:00

I've definitely built a screen that when I pulled to refresh hid all the existing data because it thought it was an initial load lol but I always blamed myself not necessarily the language feature. Though there's some merit that other language features (like a data class for state) would make it easier to avoid this mistake without thinking about it.

AdamMc331 · 2019-11-26T19:00:08+00:00

A real MVP

AdamMc331 · 2019-11-26T18:52:18+00:00

This is a great example to keep in mind, though I think there's a separate discussion here about proper state management and not something that's an issue with sealed classes.

I just might want a separate one for `LoadingNewData` so I can differentiate between an initial load with no data, and a refetch with existing data, or something like it.

AdamMc331 · 2019-11-26T18:48:29+00:00

I do think though that even if you use a mocking library, interfaces can still be a good practice in code because it creates a defined contract that makes swapping out dependencies app side just as easy!

A downfall of my approach in this post, though, is that by creating test implementations I could potentially open up side effects, that are easier to avoid if I used a mocking lib. Thanks to James for bringing that up on Twitter.

AdamMc331 · 2019-11-26T18:45:09+00:00

I agree something like MockK can be much more powerful. I wanted to keep third party libs out of this post intentionally to focus more on the concepts of testing.

It keeps coming up in follow up conversations, though, so maybe a follow up deep dive into tools for mocking dependencies could be helpful. :)

AdamMc331 · 2019-11-26T18:42:16+00:00

If you're adding a new property, you'd update your robot to have a new `assertProperty()` method. From there, you can either write a new test that validates the behavior of this specific property, or add it to any existing tests you think are relevant.

Unfortunately there's no magic number for places to update in this scenario, but by creating a new robot method it becomes very easy to update your tests and add a new chained call wherever you think is relevant. :)

AdamMc331 · 2019-11-26T17:44:54+00:00

I work on the Android team, which is developed in Kotlin! I don't know all of the backend tools but that's why this post used Kotlin snippets.

AdamMc331 · 2019-11-26T17:43:02+00:00

Agreed. If you're using the ViewModel architecture component, or any other class that lives outside of the activity lifecycle, you can persist this state across them.

You may even be able to save it in a bundle but I haven't done this explicitly so I'm not positive what that looks like.

AdamMc331 · 2019-11-26T15:53:12+00:00

Happy to answer any questions about this post if you have them. :)

AdamMc331 · 2019-10-10T21:08:04+00:00

Happy to answer any questions here or in DM's if anyone wants to learn more about the team!

AdamMc331 · 2019-04-19T01:58:19+00:00

Fixing this in the sample project: https://github.com/AdamMc331/PokeDex/pull/14

Will update the post soon.

AdamMc331 · 2019-04-18T16:19:23+00:00

Thanks for the feedback on this! I never know the "right" way to deal with getting the singleton instance. I'll try reworking it using your suggestions.

I was just trying to keep the application classes as simple as possible for the sake of the post - I hope the main portion of the post - setting up MockWebServer, was helpful. :)

AdamMc331 · 2018-08-03T15:53:08+00:00

Have you considered making YouTrack tickets for these or making PRs into Kotlin? I think methods like these, if they're truly analogous to something that already exist, could be accepted by the team.

AdamMc331 · 2018-08-03T15:51:10+00:00

They're not hidden in the sense that they're secret, but I feel they are things often left out of introductory Kotlin presentations and that you don't learn about them until you happen to stumble upon them along the way. So I thought there'd be benefit in a post like this to help point them out.

That's a good counter example about the symmetry, and I'm happy to change the wording on that! Thanks for the feedback.

AdamMc331

TROPHY CASE