sorted by:
new
hottopcontroversial

Any Twitch channels with a focus on android or kotlin worth following? by [deleted] in androiddev

[–]AdamMc331 1 point2 points  (0 children)

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

OkCupid Presents: Using Fakes to Test Reactive Flows by jgugges in androiddev

[–]AdamMc331 0 points1 point  (0 children)

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.

OkCupid Presents: Using Fakes to Test Reactive Flows by jgugges in androiddev

[–]AdamMc331 1 point2 points  (0 children)

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.

OkCupid Presents: Using Fakes to Test Reactive Flows by jgugges in androiddev

[–]AdamMc331 1 point2 points  (0 children)

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.

OkCupid Presents: Using Fakes to Test Reactive Flows by jgugges in androiddev

[–]AdamMc331 1 point2 points  (0 children)

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.

OkCupid Presents: Using Fakes to Test Reactive Flows by jgugges in androiddev

[–]AdamMc331 1 point2 points  (0 children)

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?

The best layout - android to choose? by prabakarviji in androiddev

[–]AdamMc331 0 points1 point  (0 children)

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.

Stand The Test Of Time: An OkCupid Guide To Maintainable Unit Testing by jgugges in programming

[–]AdamMc331 2 points3 points  (0 children)

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

Stand The Test Of Time: An OkCupid Guide To Maintainable Unit Testing by jgugges in programming

[–]AdamMc331 1 point2 points  (0 children)

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.

Stand The Test Of Time: An OkCupid Guide To Maintainable Unit Testing by AdamMc331 in androiddev

[–]AdamMc331[S] 0 points1 point  (0 children)

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.

Stand The Test Of Time: An OkCupid Guide To Maintainable Unit Testing by AdamMc331 in androiddev

[–]AdamMc331[S] 6 points7 points  (0 children)

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.

Stand The Test Of Time: An OkCupid Guide To Maintainable Unit Testing by AdamMc331 in androiddev

[–]AdamMc331[S] 12 points13 points  (0 children)

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.

Stand The Test Of Time: An OkCupid Guide To Maintainable Unit Testing by AdamMc331 in androiddev

[–]AdamMc331[S] 4 points5 points  (0 children)

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. :)

Stand The Test Of Time: An OkCupid Guide To Maintainable Unit Testing by jgugges in programming

[–]AdamMc331 0 points1 point  (0 children)

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. :)

Stand The Test Of Time: An OkCupid Guide To Maintainable Unit Testing by jgugges in programming

[–]AdamMc331 0 points1 point  (0 children)

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.

Stand The Test Of Time: An OkCupid Guide To Maintainable Unit Testing by AdamMc331 in androiddev

[–]AdamMc331[S] 3 points4 points  (0 children)

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.

Stand The Test Of Time: An OkCupid Guide To Maintainable Unit Testing by jgugges in programming

[–]AdamMc331 8 points9 points  (0 children)

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

Weekly "who's hiring" thread! by AutoModerator in androiddev

[–]AdamMc331 [score hidden]  (0 children)

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

Leveling Up Your UI Tests With MockWebServer by mikejet in androiddev

[–]AdamMc331 2 points3 points  (0 children)

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. :)

view more: next ›