search

Droidcon-Boston / conference-app-android

Official conference app for Droidcon Boston
http://www.droidcon-boston.com/
Apache License 2.0
98 stars 25 forks source link

Start Writing Tests #138

Open AdamMc331 opened 5 years ago

AdamMc331 commented 5 years ago

Creating a broad ticket to write some tests for our existing functionality. Haven't begun to dug into this so I'm not sure what will happen yet, but this is to track progress.

CCorrado commented 5 years ago

If you guys aren't opposed, for the user profile/registration stuff I am inclined to write some tests :) I have been into MVP patterns + JUnit + Mockito lately at work, but whatever you guys decide here I'll follow along!

AdamMc331 commented 5 years ago

I'm sure Giorgio would appreciate the help! I was going to start by combing through the non UI files first and getting in some basic JUnit tests where I can, and take note of anywhere that can be refactored.

I can defer to you on the login related files for now. :)

imGurpreetSK commented 5 years ago

Hi. Can I help with this issue?

AdamMc331 commented 5 years ago

Sure! Any help is appreciated, we don't have a lot of test coverage yet. Feel free to see #140 for what we have now.

The tests are mostly for data classes. I looked inside the views package and saw that a lot of it seemed pretty tightly coupled together. It's hard to write unit tests for fragment classes. So I would move forward with a couple options:

1) We consider some UI testing and see if we can mock the data layer somehow 2) We look for opportunities to move things out of the fragments into a ViewModel class, and write unit tests around the view models.

Personally, I like the second option, but that might be tricky. If we want to do that, I think we can divide the work by package. Example: I could take the detail package and refactor/test the AgendaDetailFragment and SpeakerDetailFragment.

Does this seem like a good way to split work?

imGurpreetSK commented 5 years ago

Sorry for the late reply. I would actually like to go with the second approach as it would allow better testability and extensibility in the future. We can use MVVM/MVI to structure the code. Can you tell me whether the speaker module is a good starting point for the same?

kenyee commented 5 years ago

Speaker module would be good as well. There wasn't time to do this properly the last two years FYI...it was just "get it working"...usually 2-3 weeks before the event so it was maybe two weekends of work :-)

AdamMc331 commented 5 years ago

Haha no worries, we've all been there. Happy to help refactor it now. :)

imGurpreetSK commented 5 years ago

Have refactored the speaker module using architecture components. Yet to write tests (facing some difficulties with testing along firebase dependencies). Help/reviews welcome https://github.com/GurpreetSK95/conference-app-android/tree/gs/speakers-refactor

AdamMc331 commented 5 years ago

What part about testing with firebase? I did some firebase mocking in my branch that's up for PR. Maybe once it's merged you'll have some inspiration? I learned how to mock firebase database calls like this: https://stackoverflow.com/a/43227989/3131147